PostgreSQL 15创建索引报错“could not read block 0”求助

核心现象 #

• 在PostgreSQL 14服务器上，create index on companies ((linkedin_name(company url)));可正常执行
• 新搭建的PostgreSQL 15服务器多次恢复备份后，执行相同语句报错：could not execute query: ERROR: could not read block 0 in file "base/16387/8646581": read only 0 of 8192 bytes
• 执行create table companies2 as select * from companies;后，在companies2上创建相同索引可成功；但将companies2重命名为companies后，执行reindex会触发相同错误

可能原因 #

1. 备份恢复导致文件损坏：报错中的文件base/16387/8646581大概率是原companies表的关联存储文件（表本体、TOAST表或遗留索引文件），恢复过程中可能因IO中断、备份文件损坏、恢复工具参数错误导致文件不完整（比如大小为0字节）。
2. 系统元数据异常：虽然表数据可通过select *读取，但PostgreSQL系统目录中关于该表的文件关联信息可能存在错误，导致操作时尝试读取无效文件块。
3. 版本升级的隐性兼容性问题：PostgreSQL 14到15的内部存储格式、元数据结构有细微变化，若采用文件级备份恢复（而非逻辑导出导入），可能导致部分元数据未正确适配，引发文件访问错误。

排查步骤 #

• 定位文件关联对象：执行以下SQL，确认报错文件对应的数据库对象：

  -- 查文件对应的对象
  select oid, relname, relkind from pg_class where relfilenode = 8646581;
  -- 查数据库oid是否为16387
  select oid, datname from pg_database;
  

• 检查文件系统状态：登录PG15服务器，查看$PGDATA/base/16387/8646581的大小、权限：

  ls -lh $PGDATA/base/16387/8646581
  

  若文件大小为0，说明文件已损坏；同时检查磁盘剩余空间、是否存在坏道。
• 验证备份完整性：若使用pg_dump/pg_restore恢复，重新校验备份文件的哈希值；若为文件级备份（如pg_basebackup、rsync），检查备份过程是否存在中断、未同步的情况。

解决方法 #

1. 用完好副本替换损坏表
   既然companies2能正常创建索引，直接用它替换原表（操作前务必备份原表结构）：

   -- 导出原表的结构、约束、索引定义（可通过psql的\d companies命令查看）
   drop table companies;
   alter table companies2 rename to companies;
   -- 重新创建原有的索引、约束、触发器
   create index on companies ((linkedin_name(company url)));
   

2. 尝试修复元数据
   执行vacuum full analyze companies;，强制PostgreSQL重建表的存储文件和元数据关联。若执行时仍报错，说明文件本身损坏，需采用上述替换方案。
3. 改用逻辑备份恢复
   若之前用文件级备份恢复，改用pg_dump导出PG14的全库，再在PG15中用pg_restore导入，避免版本间的存储格式兼容性问题。
4. 检查磁盘硬件健康
   用smartctl等工具检测磁盘是否存在坏道、硬件故障，这是文件损坏的常见根源，需及时排查避免后续问题。

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