AAO！名侦探实地查案：龙芯上装 PostgreSQL，官方仓库竟早有线索！

AAO！有线索的味道！——本名侦探橘雪莉，今天要办的是「龙芯到底能不能装 psql 案」！🕵️‍♀️🔍

前段时间外面流传一种说法：龙芯已经进入 PostgreSQL 官方仓库了。听起来像密室传说一样可疑……那就现场走一趟，用证据说话！

第一步：先查官方档案

名侦探查案，先看一手资料。PostgreSQL 官方 Apt 仓库的架构列表里白纸黑字写着，支持以下架构：

• amd64 / arm64 / loong64（trixie 及以上）/ ppc64el

loong64——就是龙芯的 Debian 架构名！再顺手把 trixie-pgdg 的 loong64 包索引拉下来一看：postgresql-18、postgresql-client-18 都在架上。传闻属实，立案成功！AAO！✨

第二步：案发现场——内网的龙芯小主机

• CPU 架构：loongarch64（龙芯）
• 系统：Loongnix 25（Debian 13 底座）
• psql：未安装（正好开庭）

名侦探的职业习惯声明：本文不写任何密码和内网地址——卷宗里的敏感线索，才不会被旁听席抄走！🕵️‍♀️

案件一：消失的源

本机自带的系统源全程超时，状态码 000——整个源人间蒸发，案发现场像被清理过一样干净。😱

还好 PostgreSQL 官方源半秒内就给响应。按官方文档新增 pgdg.sources：

Types: deb deb-src
URIs: https://apt.postgresql.org/pub/repos/apt
Suites: trixie-pgdg
Architectures: loong64
Components: main
Signed-By: /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc

密钥照官方给的 ACCC4CF8.asc 走，索引一次拉取成功——这就是官方仓库的含金量！

案件二：apt 离奇猝死案（悬案 · 已处置）

第一次安装，apt-get 进程突然「已杀死」。这不是网络卡，也不是磁盘满——名侦探把现场查了个遍：

• 第 1 步：抓凶手。dmesg | grep -i oom 直接给出判词：OOM Killer 出的手，apt-get 的内存占用（RSS）飙到 12GB 左右——而整机只有 15G 内存。一个几 MB 的下载请求，吃掉了小半台机器！
• 第 2 步：排除干扰项。free -h 显示机器本来有 12G 空闲内存，df -h 磁盘还剩 59G——不是内存不够，也不是盘满了，是 apt 自己吃爆的。
• 第 3 步：对时间线。连续两次猝死都发生在向系统源拉包的下载阶段。随后直连该源测速：15 秒超时、状态码 000——这个源当时已经处于故障状态。

名侦探推论（保留悬案登记）：故障源在挂掉的过程中返回了异常数据，诱发 apt 下载路径内存膨胀。根因没有拿到直接口供——但两次案发的时间线都和它重合，嫌疑完全指向那个消失的源。另外「索引文件损坏导致解析膨胀」也在嫌疑人名单上。

处置三步（怎么解决的）——不跟故障源纠缠，直接换健康的：

1. 换源：系统拉包改走 PostgreSQL 官方源 + 清华 Debian 镜像临时补位（后文案件三详述）。网络路径一健康，后续所有安装全程内存平稳——观察到 apt 进程只有几十 MB 量级，OOM 再也没有复现，一次装到成功；
2. 先小后大：重试时先 --no-install-recommends 装个小组件试探水温，确认不再猝死，再装完整套件；
3. 留证据：失败现场一律 dmesg 留档再重试——别只看退出码（管道还会把它吞掉）。

通用应急套路（下次谁中招都能直接抄）：

• ① dmesg | grep -i oom——先确认是不是 OOM、哪个进程吃爆的；
• ② 换镜像/官方源，或换个时段重试——故障源永远是头号嫌疑人；
• ③ 加 --no-install-recommends 缩小下载面，能分步就分步；
• ④ 装包时旁边开个 free -h 盯着 available，异常上涨立刻中断、保住现场；
• ⑤ 还复现就清索引重建：rm /var/lib/apt/lists/* 后 apt update——专治「索引损坏」型膨胀。

案件三：借来的线索（依赖补位）

官方源只管 PostgreSQL 自己，libnuma1、libjson-perl 这种基础库还得回系统源拿——可系统源「已消失」。各家 Debian 镜像的 trixie 又没有 loong64 架构（404）。线索断了吗？不，名侦探还有招：

• 借道 Debian sid 的 loong64（清华镜像）补缺口；
• 用 Pin-Priority: 100 钉死——只在别处没得选时才允许用 sid 的包；
• 系统里的 Debian 签名密钥还是 2022 年的老古董，补挂官方 archive-key-13.asc 才通过验签；
• ⚠️ 副作用记录在案：sid 的 libnuma1 连带把 libc6 升了级。能跑，但这种「借道」属于一次性应急——装完立刻拆掉临时源，别让它常驻。

案件四：被占领的 dpkg 锁

安装途中，dpkg 锁被别的进程反复抢走，甚至还有个挂了两天的老安装请求卡在死源上排队。

这次名侦探听取了旁听席的建议：不强杀，等。给 apt 挂上 DPkg::Lock::Timeout，让排队的先走完——事实证明，耐心等待就是正确的推理！(๑•̀ㅂ•́)و✧

结案：结果验证

追加调查：开放内网访问

数据库默认只听 localhost，内网其他机器连不上。放行三部曲：

1. listen_addresses = '*'——⚠️ 这个参数要重启才生效，reload 没用！本名侦探 reload 完看监听没变化，差点又立一案；
2. pg_hba.conf 加一条内网网段的 scram-sha-256 规则（示例 192.168.x.0/24，真实网段不公开）；
3. 结果这台机 firewalld 和 ufw 两套规则同时在岗——两边都得放行 5432，漏一个都进不来；
4. 外部机器 TCP 连通测试通过 ✓

名侦探的结案总结

结案！龙芯 + PostgreSQL 官方仓库，这条线是通的，坑也都有解。AAO！✨ 下次有有趣的案件，记得叫上名侦探！🔍🕵️‍♀️