pg_restore 给扩展写注释时报 must be owner of extension

pg_restore 恢复到已有数据库，报错指向 pg_trgm：

ERROR: must be owner of extension pg_trgm

先查看错误对应的 SQL 和归档目录项。如果是 COMMENT ON EXTENSION pg_trgm，失败的是给扩展写注释。它与扩展创建失败、找不到共享库或业务对象恢复失败，需要分别处理。

数据库所有者不一定拥有这个扩展

扩展可能在恢复前由另一个管理角色安装。恢复中的 CREATE EXTENSION IF NOT EXISTS 遇到同名扩展时不会重新创建，也不会把它的所有权交给当前角色；后续写注释仍受扩展所有权限制。

在实际恢复目标库检查当前身份和扩展记录：

SELECT current_database(), session_user, current_user;

SELECT extname, extversion, pg_get_userbyid(extowner) AS owner,
       obj_description(oid, 'pg_extension') AS comment
FROM pg_extension
WHERE extname = 'pg_trgm';

extowner 才是扩展所有者。数据库所有者、schema 所有者、某张业务表的所有者，都不能直接代替它。普通对象授权也不会改变扩展所有权。

在托管数据库中，还要确认账号的实际权限。账号名称带有 admin 或 superuser，并不能证明它具有 PostgreSQL 的超级用户属性。

只跳过注释，还是保留这些元数据

如果完整日志确认只有扩展注释失败，且业务不依赖恢复这些注释，可以评估跳过相应注释。现代版本的 pg_restore 提供 --no-comments，它会跳过整轮恢复中的注释，不只是 pg_trgm 的那一条；先用实际工具的 --help 确认支持，再判断是否接受其他对象的说明也不恢复。

需要保留其他注释时，可先列出归档目录：

pg_restore --list backup.dump > restore.list

backup.dump 与 restore.list 是示例文件名。核对目录中准确的 COMMENT EXTENSION pg_trgm 项，在该行开头加分号，将它排除；其余条目及顺序保留。经过复核的清单由 --use-list=restore.list 用于后续恢复。这里调整的是恢复选择，并没有删除数据库中的扩展。

若必须恢复这条注释，应由拥有该扩展且获准执行操作的维护角色处理。不要为了注释元数据直接删掉再重建扩展，也不要给业务账号长期增加超级用户权限。

--no-owner 只省略恢复对象所有权的相关命令，不等于跳过 COMMENT。--clean 会尝试删除待恢复对象，也不是注释权限错误的通用修复方式。已有数据或对象的库需要先确认恢复方案与备份，不能为了得到零错误的日志随手添加它。

确认没有其他恢复错误，再接受结果

读完整恢复日志和退出状态，确认没有扩展创建、类型、函数、操作符、数据、索引或约束错误。若有这些错误，应处理对应失败，不能因为看到了一个注释错误，就把所有错误都归为“可以忽略”。

检查扩展版本和依赖它的业务查询，再按业务要求核对关键数据与对象。只有注释未恢复且已确认可以接受，与整份数据库成功恢复，是两个需要分别记录的判断。

如果日志改为 could not load library，转去检查目标版本的扩展库安装与升级兼容性。如果 must be owner 指向的是分区父表，应检查创建分区的所有者权限，不要沿用扩展注释的处理办法。