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
-
Stabilize 035_standby_logical_decoding.pl.
- 105b2cb33617 18.0 landed
- 17a165d60f73 17.5 landed
- 86392e8827d8 16.9 landed