业务写入全失败，日志里是 ERROR: could not extend file 后面跟着 No space left on device，读请求也开始超时。日志里能对上时间点，这种反而好排。
WAL 和临时文件把数据目录所在分区写满，PG 没有预留空间，连 checkpoint 都写不下去，只能整体拒绝写入，重启也救不回来。这一点先确认清楚，后面就不用反复试。
df -h /var/lib/postgresql du -sh /var/lib/postgresql/*/pg_wal SELECT pg_switch_wal();
这次卡住的地方就在「PG 磁盘满写入失败」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：先用 df -h 看清是数据分区满还是 WAL 分区满，两者处理不同；清掉可以重建的临时文件，再归档堆积的旧 WAL；先停掉大批量导入和归档任务再恢复业务写入。
结果对不对很好判断，写入恢复正常，pg_wal 目录不再增长，磁盘占用回落到八成以下。