Re: pgsql: Preserve conflict-relevant data during logical replication. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pgsql: Preserve conflict-relevant data during logical replication.
Date
Msg-id CAA4eK1KtGYqgan+TSJ_+6rozHUu00NYtAMbEJy0RagK3fFp58w@mail.gmail.com
Whole thread Raw
In response to RE: pgsql: Preserve conflict-relevant data during logical replication.  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Wed, Sep 3, 2025 at 5:10 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Tuesday, September 2, 2025 11:03 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Wed, Jul 23, 2025 at 11:44 PM Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> >
> > If it is in fact important to acquire the commit timestamp after setting
> > delayChkptFlags, you'd hope this would lead to a test failure, but it doesn't for
> > me. I understand it probably requires an injection point to be certain of hitting
> > the race condition, but I think that would be worth doing. Otherwise, if
> > something gets broken here by accident, it might be a long time before anyone
> > notices.
>
> Thanks for pointing it out!
>
> I agree that adding a test is valuable to mitigate the risk of future code
> changes. We added a similar safeguard for the RecordTransactionCommit() function
> by adding Assert(xactStopTimestamp == 0) after marking the DELAY_CHKPT_xxx flag,
> and did not do any precautionary check for RecordTransactionCommitPrepared as
> the code to acquire the timestamp and setting flag was close by and had explicit
> comments.
>
> I'll prepare a test case that uses the injection point and share it in the
> original thread.
>

The test for this case is added in commit
6456c6e2c4ad1cf9752e09cce37bfcfe2190c5e0.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Alyona Vinter
Date:
Subject: Re: Timeline switching with partial WAL records can break replica recovery
Next
From: Zsolt Parragi
Date:
Subject: Re: OAuth client code doesn't work with Google OAuth