Re: Conflict Detection and Resolution

On Tue, Aug 27, 2024 at 1:51 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)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