On Tue, Aug 27, 2024 at 1:51 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > Please find v10 patch-set. Changes are: > > 1) patch-001: > - Corrected a patch application warning. > - Added support for pg_dump. > - As suggested in pt.4 of [1]: added a warning during CREATE and > ALTER subscription when track_commit_timestamp is OFF. > > 2) patch-002 & patch-003: > - Reduced code duplication in execReplication.c > - As suggested in pt.4 of [2]: Optimized the pre-scan for > insert_exists and update_exists cases when resolver is set to ERROR. > - Fixed a bug reported by Shveta in [3] > > Thank You Ajin for working on pg_dump support changes. >
Thank You for the patches. Few comments for pg_dump 1) If there are multiple subscriptions with different resolver configuration, pg_dump currently dumps resolver in different orders for each subscription. It is not a problem, but it will be better to have it in the same order. We can have an order-by in the pg_dump's code while querying resolvers. 2) Currently pg_dump is dumping even the default resolvers configuration. As an example if I have not changed default configuration for say sub1, it still dumps all: CREATE SUBSCRIPTION sub1 CONNECTION '..' PUBLICATION pub1 WITH (....) CONFLICT RESOLVER (insert_exists = 'error', update_differ = 'apply_remote', update_exists = 'error', update_missing = 'skip', delete_differ = 'apply_remote', delete_missing = 'skip'); I am not sure if we need to dump default resolvers. Would like to know what others think on this. 3) Why in 002_pg_dump.pl we have default resolvers set explicitly? thanks Shveta
