损坏PostgreSQL数据库迁移时pg_dump执行报错的相关问题咨询

直接执行以下SQL即可获取所有序列和所属表、字段的对应关系，结果可以直接用来生成你需要的ALTER TABLE配置语句：

SELECT 
    n.nspname AS schema_name,
    t.relname AS table_name,
    a.attname AS column_name,
    s.relname AS sequence_name
FROM 
    pg_class s
    JOIN pg_depend d ON d.objid = s.oid
    JOIN pg_class t ON d.refobjid = t.oid
    JOIN pg_attribute a ON (d.refobjid = a.attrelid AND d.refattnum = a.attnum)
    JOIN pg_namespace n ON t.relnamespace = n.oid
WHERE 
    s.relkind = 'S'
    AND d.deptype = 'a'
ORDER BY 
    n.nspname, t.relname, a.attname;

你遇到的pg_dump报错属于系统表关联的TOAST块损坏，报错中pg_toast_2618对应存储视图定义的系统表TOAST分区，坏块出现在某个视图的定义存储上，所以单独导出用户表不会触发问题，全库备份读取视图定义时才会报错。
同类场景的常规处理流程：

1. 执行SELECT oid,relname,relnamespace FROM pg_class WHERE oid=78478;定位到损坏的视图
2. 备份该视图的创建语句后删除视图，再执行全库pg_dump即可正常完成
3. 备份完成后在旧库和新库重新创建该视图即可

• 序列当前值未同步：仅配置默认值不会同步序列的当前值，迁移完成后需要将旧库序列的last_value同步到新库，否则插入数据会触发主键冲突
• 字符集排序规则兼容：如果新旧库的lc_collate配置不一致，会导致索引失效、字符串排序结果不符合预期的问题
• 扩展插件版本差异：旧库安装的第三方扩展（如postgis、pg_trgm等）如果和新高版本库的扩展版本不兼容，会导致数据无法导入或者功能异常
• 存储过程语法兼容：高版本PostgreSQL对PL/pgSQL的语法检查更严格，旧版本可正常运行的存储过程、触发器在高版本可能报错
• 大对象、权限数据遗漏：分片备份容易遗漏大对象(LO)数据、角色权限配置、表空间配置等全局数据

• pg_upgrade：PostgreSQL官方自带的跨版本升级工具，支持原地升级和离线升级，适合大库场景，停机时间远短于逻辑备份迁移
• pglogical：官方支持的逻辑复制插件，可以实现旧库到高版本新库的增量同步，追平数据后可无缝切流，实现接近零停机的迁移
• pg_basebackup：物理备份工具，适合同大版本下的跨小版本迁移，速度远快于逻辑备份
• pg_dump/pg_restore：最通用的逻辑迁移工具，兼容性最高，支持跨任意大版本迁移，就是你目前使用的方案

• 优先修复坏块后全量备份：按上述方法定位并修复损坏的视图后，直接用pg_dump做全量备份，比分片手动拼接数据的风险低很多，出错概率更小
• 逻辑复制迁移：在旧库安装对应版本的pglogical插件，新高版本库作为订阅端，全量同步完成后持续同步增量数据，适合无法长时间停机的生产场景
• 物理备份+pg_upgrade升级：如果允许短时间停机，可先停止旧库业务，做全量物理备份，在新环境用pg_upgrade直接将数据文件升级到目标版本，适合100G以上的大库，迁移速度是逻辑备份的数倍

内容的提问来源于stack exchange，提问作者Виктор Кадкин