Re: Conflict Detection and Resolution

On Thu, Jun 20, 2024 at 6:41 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> >> In the second patch, we can implement simple built-in resolution
> >> strategies like apply and skip (which can be named as remote_apply and
> >> keep_local, see [3][4] for details on these strategies) with ERROR or
> >> LOG being the default strategy. We can allow these strategies to be
> >> configured at the global and table level.

Before we implement resolvers, we need a way to configure them. Please
find the patch002 which attempts to implement Global Level Conflict
Resolvers Configuration.  Note that patch002 is dependent upon
Conflict-Detection patch001 which is reviewed in another thread [1].
I have attached patch001 here for convenience and to avoid CFBot
failures. But please use [1] if you have any comments on patch001.

New DDL commands in patch002 are:

To set global resolver for given conflcit_type:
SET CONFLICT RESOLVER 'conflict_resolver' FOR 'conflict_type'

To reset to default resolver:
RESET CONFLICT RESOLVER FOR 'conflict_type'

TODO: Once we get initial consensus on DDL commands, I will add
support for them in pg_dump/restore and will add doc.

------------

As suggested in [2] and above, it seems logical to have table-specific
resolvers configuration along with global one.

Here is the proposal for table level resolvers:

1) We can provide support for table level resolvers using ALTER TABLE:

ALTER TABLE <name> SET CONFLICT RESOLVER <resolver1> on <conflict_type1>,
                                       SET CONFLICT RESOLVER
<resolver2> on <conflict_type2>, ...;

Reset can be done using:
ALTER TABLE <name> RESET CONFLICT RESOLVER on <conflict_type1>,
                                      RESET CONFLICT RESOLVER on
<conflict_type2>, ...;

Above commands will save/remove configuration in/from the new system
catalog pg_conflict_rel.

2) Table level configuration (if any) will be given preference over
global ones. The tables not having table-specific resolvers will use
global configured ones.

3) If the table is a partition table, then resolvers created for the
parent will be inherited by all child partition tables. Multiple
resolver entries will be created, one for each child partition in the
system catalog (similar to constraints).

4) Users can also configure explicit resolvers for child partitions.
In such a case, child's resolvers will override inherited resolvers
(if any).

5) Any attempt to RESET (remove) inherited resolvers on the child
partition table *alone* will result in error:  "cannot reset inherited
resolvers" (similar to constraints). But RESET of explicit created
resolvers (non-inherited ones) will be permitted for child partitions.
On RESET, the resolver configuration will not fallback to the
inherited resolver again. Users need to explicitly configure new
resolvers for the child partition tables (after RESET) if needed.

6) Removal/Reset of resolvers on parent will remove corresponding
"inherited" resolvers on all the child partitions as well. If any
child has overridden inherited resolvers earlier, those will stay.

7) For 'ALTER TABLE parent ATTACH PARTITION child'; if 'child' has its
own resolvers set, those will not be overridden. But if it does not
have resolvers set, it will inherit from the parent table. This will
mean, for say out of 5 conflict_types, if the child table has
resolvers configured for any 2, 'attach' will retain those; for the
rest 3, it will inherit from the parent (if any).

8) Detach partition will not remove inherited resolvers, it will just
mark them 'non inherited' (similar to constraints).

Thoughts?

------------

[1]:
https://www.postgresql.org/message-id/OS0PR01MB57161006B8F2779F2C97318194D42%40OS0PR01MB5716.jpnprd01.prod.outlook.com
[2]: https://www.postgresql.org/message-id/4738d098-6378-494e-9f88-9e3a85a5de82%40enterprisedb.com

thanks
Shveta