RE: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From Zhijie Hou (Fujitsu)
Subject RE: Conflict detection for update_deleted in logical replication
Date
Msg-id OS0PR01MB57160C92142C9D1912E48C169427A@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Conflict detection for update_deleted in logical replication
List pgsql-hackers
On Thursday, July 31, 2025 5:26 PM shveta malik <shveta.malik@gmail.com> wrote:
> 
> On Tue, Jul 29, 2025 at 10:51 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
> wrote:
> >
> >
> > This is the V54 patch set, with only patch 0001 updated to address the
> > latest comments.
> >
> 
> Thanks for the patch.
> 
> While performing tests on the latest patch, I found an assert in tablesync
> worker in FindDeletedTupleInLocalRel (see
> Assert(TransactionIdIsValid(oldestxmin))). Logs at [1].
> 
> It seems table sync worker is trying to apply changes and going to
> update-deleted conflict detection patch but is not able to find
> MyLogicalRepWorker->oldest_nonremovable_xid as this xid is set only
> for apply-worker.

Thanks for reporting. I have fixed it by referring to conflict detection slot's
xmin instead of the leader worker's oldest_nonremovable_xid. This should
be safe because the slot.xmin is always valid.

Best Regards,
Hou zj

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication
Next
From: Ajin Cherian
Date:
Subject: Re: 024_add_drop_pub.pl might fail due to deadlock