Re: Conflict Detection and Resolution

On Mon, Jul 1, 2024 at 1:17 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
>
>
> On Thu, Jun 27, 2024 at 1:14 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>>
>> Please find the attached  'patch0003', which implements conflict
>> resolutions according to the global resolver settings.
>>
>> Summary of Conflict Resolutions Implemented in 'patch0003':
>>
>> INSERT Conflicts:
>> ------------------------
>> 1) Conflict Type: 'insert_exists'
>>
>> Supported Resolutions:
>> a) 'remote_apply': Convert the INSERT to an UPDATE and apply.
>> b) 'keep_local': Ignore the incoming (conflicting) INSERT and retain
>> the local tuple.
>> c) 'error': The apply worker will error out and restart.
>>
>
> Hi Nisha,
>
> While testing the patch, when conflict resolution is configured and insert_exists is set to "remote_apply", I see
thiswarning in the logs due to a resource not being closed: 
>
> 2024-07-01 02:52:59.427 EDT [20304] LOG:  conflict insert_exists detected on relation "public.test1"
> 2024-07-01 02:52:59.427 EDT [20304] DETAIL:  Key already exists. Applying resolution method "remote_apply"
> 2024-07-01 02:52:59.427 EDT [20304] CONTEXT:  processing remote data for replication origin "pg_16417" during message
type"INSERT" for replication target relation "public.test1" in transaction 763, finished at 0/15E7F68 
> 2024-07-01 02:52:59.427 EDT [20304] WARNING:  resource was not closed: [138] (rel=base/5/16413, blockNum=0,
flags=0x93800000,refcount=1 1) 
> 2024-07-01 02:52:59.427 EDT [20304] CONTEXT:  processing remote data for replication origin "pg_16417" during message
type"COMMIT" in transaction 763, finished at 0/15E7F68 
> 2024-07-01 02:52:59.427 EDT [20304] WARNING:  resource was not closed: TupleDesc 0x7f8c0439e448 (16402,-1)
> 2024-07-01 02:52:59.427 EDT [20304] CONTEXT:  processing remote data for replication origin "pg_16417" during message
type"COMMIT" in transaction 763, finished at 0/15E7F68 
>
Thank you Ajin for reporting the issue, This is now fixed with the
v4-0003 patch.

--
Thanks,
Nisha