PostgreSQL中如何保持FDW导入的外部表与源表同步更新

你对FDW的基础认知是准确的：外部表仅在本地存储表结构元数据，不占用本地存储空间保存业务数据，每次查询外部表时，postgres_fdw会将符合规则的查询推送到远程库执行，拉取实时结果返回。

针对第一个问题的解答 #

• 只要远程库删表重建后，表所在的schema、表名和之前完全一致，外部表查询时会自动连接到新建成的同名表拉取数据，外部表本身不会出现数据陈旧的问题——它本地根本没存历史数据，不存在缓存旧数据的可能。
• 这里不需要担心“外部表绑定旧表OID”的问题：postgres_fdw默认按「远程schema名+表名」匹配远程对象，不是按PostgreSQL内部的表OID绑定，旧表删除后新建的同名表，会被正常识别。
• 你场景里唯一会出现数据陈旧的对象是基于外部表创建的物化视图：物化视图会把查询结果实际存储在本地磁盘，不管远程源表怎么变，只要你不手动执行REFRESH MATERIALIZED VIEW MV1;，它会一直保留创建时/上次刷新时拉取的旧数据，这是物化视图的固有机制，和源表的更新方式无关。
• 只要重建后的源表结构和本地外部表定义兼容，不需要重新导入外部表就能查到新表的实时数据，但必须刷新物化视图才能拿到最新结果。

针对第二个问题的解答 #

哪怕源表采用删后重建的方式更新，结构不同步的风险依然存在，甚至比在线ALTER表更隐蔽：

• 本地存储的外部表定义，是你第一次执行IMPORT FOREIGN SCHEMA时从远程拉取的结构快照（包含列顺序、列名、列类型等映射关系），PostgreSQL没有任何后台任务会自动同步远程表的结构变化，不管远程是改表还是删了重建，本地的外部表定义都不会自动更新。
• 不要默认“重建的表结构肯定和旧表一致”：只要重建时出现列顺序调整、列类型变更、增减列的情况，查询外部表时要么直接抛类型不匹配、列不存在的错误，要么出现列数据错位映射的隐蔽问题——比如你把int类型的user_id列和varchar类型的user_name列顺序写反了，查询不会报错，但返回的数据完全是错的，很难排查。
• 最稳妥的处理方式是每次远程重建源表后，在本地执行带replace选项的外导命令更新外部表定义，这个操作不会覆盖你在本地给外部表配置的权限、注释，只会同步最新的表结构：

IMPORT FOREIGN SCHEMA completed LIMIT TO (tbl1,tbl2)
FROM SERVER db_data_pipeline
INTO public
OPTIONS (replace TRUE);

结构同步完成后再刷新物化视图，就能完全避免结构不兼容、数据不一致的问题。

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