PostgreSQL数据库连接失败求助：缓存查找及元数据关系错误

核心问题分析 #

这两个报错指向目标数据库内部系统对象损坏：access method 203是PostgreSQL用于管理表/索引访问的核心系统对象，metadata关系不存在则说明系统元数据表或业务自定义元数据表损坏。仅单个数据库受影响，说明是该库的系统目录损坏，而非整个PostgreSQL实例问题。

排查步骤 #

• 检查系统目录完整性
  用postgres超级用户通过命令行登录服务器（避免pgAdmin连接问题干扰），执行以下SQL检查目标数据库：

  -- 替换your_db为报错的数据库名
  \c your_db
  -- 检查oid=203的访问方法记录
  SELECT amname FROM pg_am WHERE amoid = 203;
  -- 查找所有含metadata的表
  SELECT tablename FROM pg_tables WHERE tablename LIKE '%metadata%';
  

  若第一条查询无返回，说明pg_am系统表缺失了对应访问方法记录；第二条无返回则确认metadata表已损坏或被误删。

• 验证自定义对象状态
  如果metadata是业务自定义表，检查是否被删除：

  SELECT relname FROM pg_class WHERE relname = 'metadata';
  

  无返回则表已被删除；有返回则需检查其权限或依赖对象是否损坏。

修复方案 #

方案1：从备份恢复（最安全） #

若有该数据库的最近备份，优先使用此方式：

1. 终止目标数据库的所有连接：

   SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'your_db';
   

2. 删除损坏数据库：

   DROP DATABASE your_db;
   

3. 从备份文件恢复：

   # 替换备份路径和数据库名
   pg_restore -d your_db /path/to/your_backup.dump
   

方案2：修复系统目录（无备份时尝试，风险高） #

无备份时可尝试修复系统表：

1. 切换到目标数据库，重新注册oid=203的访问方法（通常为btree）：

   INSERT INTO pg_am (amoid, amname, amhandler, amtype)
   VALUES (203, 'btree', 'btreehandler'::regproc, 'i');
   

2. 若metadata是系统相关表，可尝试重置WAL日志（操作前务必确认无其他可用方案，可能丢失数据）：

   sudo systemctl stop postgresql
   # 替换为你的PostgreSQL数据目录
   pg_resetwal -D /var/lib/postgresql/14/main
   sudo systemctl start postgresql
   

方案3：导出可恢复数据重建数据库 #

若部分表仍可访问：

1. 导出正常表的数据：

   # 替换table1、table2为可访问的表名
   pg_dump -t table1 -t table2 your_db > recover_data.sql
   

2. 删除并重建数据库：

   DROP DATABASE your_db;
   CREATE DATABASE your_db;
   

3. 导入恢复的数据：

   psql -d your_db -f recover_data.sql
   

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