执行大型PostgreSQL脚本触发‘设备上没有剩余空间’错误求助

核心原因：短时间磁盘占用峰值触发限制 #

你遇到的问题确实和PostgreSQL的临时文件/日志累积有关，结合Docker+Ansible的环境，具体原因有这几点：

• WAL日志累积：虽然默认是自动提交（每条INSERT单独提交），但PostgreSQL的预写日志（WAL）会先记录所有修改。一次性跑30万条INSERT时，WAL文件会快速生成，而日志清理（checkpoint）可能跟不上写入速度，短时间内占满磁盘。拆分后每次小批量执行完，checkpoint会及时清理旧WAL，不会累积到触发空间不足的程度。
• 建索引时的临时排序文件：脚本最后才创建索引，此时数据库要对全量30万条数据做排序生成索引，会生成远超最终索引大小的临时工作文件。拆分执行的话，每次建索引只处理1/10的数据，临时文件体积小很多，不会撑爆磁盘。
• Docker容器的磁盘限制：Docker容器如果用了临时存储（比如tmpfs）或者设置了磁盘配额，单脚本执行时的磁盘占用峰值会超过容器的可用空间，而拆分后峰值更低，不会触发限制。另外容器的挂载目录如果是宿主机的小分区，也容易出现这个问题。
• Ansible的脚本传输缓冲：Ansible执行时可能会把整个大SQL脚本先传到容器内的临时目录，这额外占用了容器的磁盘空间，拆分后每个小脚本体积小，不会有这个问题。

解决办法 #

• 手动分批提交：在脚本里给INSERT加事务控制，比如每1000条包在一个事务里，减少WAL的累积：

  BEGIN;
  INSERT INTO table_name VALUES (...);
  INSERT INTO table_name VALUES (...);
  -- 凑够1000条后
  COMMIT;
  

• 调整WAL参数临时优化：执行脚本前临时调大wal_buffers（比如设为64MB），或者缩短checkpoint_timeout（比如设为5分钟），让WAL更快被清理。执行完记得改回默认值，避免影响日常性能。
• 先建索引再插数据：如果业务允许，把创建索引的语句移到创建表之后、INSERT之前。虽然单条INSERT会因为维护索引变慢，但能避免全量建索引时的大临时文件，总磁盘占用会更低。
• 检查Docker磁盘配置：用docker inspect <你的PG容器名>查看挂载的存储路径，确保是宿主机的持久化大分区，而非临时存储；如果有磁盘配额，调大配额或者取消限制。
• 优化Ansible执行方式：用Ansible的postgresql_script模块直接执行脚本，或者让psql从宿主机读取脚本（比如docker exec <容器名> psql -U <用户名> -d <库名> -f /宿主机挂载的路径/脚本.sql），避免在容器内生成大临时文件。

内容的提问来源于stack exchange，提问作者codebox