Mac下Docker部署PostgreSQL导入数据报磁盘满错误求助

以下是针对该问题的具体排查方向和解决思路：

1. 排查PostgreSQL临时文件与WAL日志占用 #

批量事务加载时，PostgreSQL会生成大量WAL预写日志和临时文件，这些文件的占用可能超出预期：

• 检查容器内临时目录空间：

  docker exec <你的容器ID> df -h /tmp
  

• 查看WAL日志目录的实际占用：

  docker exec <你的容器ID> du -sh /var/lib/postgresql/data/pg_wal
  

• 若批量加载未及时提交，WAL日志会持续累积，尤其是默认开启full_page_writes参数时，WAL体积会显著增大。可尝试拆分更小的批次提交，或临时调整WAL相关参数（如wal_buffers）后再测试。

2. 验证Docker VM的实际可用空间 #

虽然Docker VM分配了104GB资源，但可能存在实际空间偏差：

• 打开Docker Desktop → 设置 → 资源 → 磁盘，查看VM磁盘的实际已用与剩余空间
• 清理Docker未使用的镜像、容器、卷等资源：

  docker system prune -a --volumes
  

  注意：执行前请备份重要数据。

3. 检查文件系统inode是否耗尽 #

磁盘空间充足但仍报"no space left"，可能是inode耗尽导致：

• 检查容器内数据目录的inode使用情况：

  docker exec <你的容器ID> df -i /var/lib/postgresql/data
  

若inode使用率接近100%，则需要清理数据目录内的小文件，或重建Docker卷调整inode配置。

4. 确认PostgreSQL数据卷的挂载与镜像问题 #

• 检查数据卷的挂载类型，确保是独立的Docker卷而非容器内部层：

  docker exec <你的容器ID> mount | grep /var/lib/postgresql/data
  

• 尝试更换官方Postgres镜像（如postgres:17-alpine）测试，排除当前Debian镜像的特定配置问题；同时手动在容器内创建更大的文件（如30GB），验证文件系统本身是否存在大小限制：

  docker exec <你的容器ID> truncate -s 30G /var/lib/postgresql/data/test_large_file
  

5. 优化批量加载逻辑 #

导入数据时的索引、约束会大幅增加磁盘开销：

• 导入前临时禁用表的触发器和索引：

  ALTER TABLE <你的表名> DISABLE TRIGGER ALL;
  DROP INDEX IF EXISTS <你的索引名>;
  

• 完成数据导入后再恢复：

  ALTER TABLE <你的表名> ENABLE TRIGGER ALL;
  CREATE INDEX <你的索引名> ON <你的表名> (<列名>);
  

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