Re: Fix 035_standby_logical_decoding.pl race conditions

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 'Amit Kapila' <amit.kapila16@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-09T05:54:53Z
Lists: pgsql-hackers
Hi,

On Wed, Apr 09, 2025 at 12:03:06PM +0900, Michael Paquier wrote:
> On Tue, Apr 08, 2025 at 06:42:53AM +0000, Bertrand Drouvot wrote:
> > Fully agree. Will need to find another way to prevent a process to wait between the
> > wakeup and the detach. I'll open a dedicated thread.
> 
> By the way, there is a small thing that's itching me a bit about the
> change done in LogStandbySnapshot() for 105b2cb33617.  Could it be
> useful for debugging to add a elog(DEBUG1) with the LSN returned by
> GetInsertRecPtr() when taking the short path?  We don't have any
> visibility when the shortcut path is taken, which seems annoying in
> the long term if we use the injection point skip-log-running-xacts for
> other tests, and I suspect that there will be some as the standby
> snapshots can be really annoying in tests where we want a predictible
> set of WAL records when wal_level is "replica" or "logical".

Yeah, I also think that would be good to have some way to debug this. That's
why I did propose to generate a WAL record by making use of LogLogicalMessage()
instead of GetInsertRecPtr() (see [1]). We could generate "bypassing xl_running_xacts"
or such and bonus point that would advance the record ptr. 

Adding an elog(DEBUG1) could make sense too.

[1]: https://www.postgresql.org/message-id/Z%2Buko5kbw/ek/h0F%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



Commits

  1. Stabilize 035_standby_logical_decoding.pl.