Re: Fix 035_standby_logical_decoding.pl race conditions
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: 'Amit Kapila' <amit.kapila16@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-01T08:32:35Z
Lists: pgsql-hackers
Hi Kuroda-san, On Tue, Apr 01, 2025 at 01:22:49AM +0000, Hayato Kuroda (Fujitsu) wrote: > Dear Bertrand, > Thanks for the updated patch! > > s/to avoid the seeing a xl_running_xacts/to avoid seeing a xl_running_xacts/? > > Fixed. hmm, not sure as I still can see: +# Note that injection_point is used to avoid the seeing the xl_running_xacts === 1 + * XXX What value should we return here? Originally this returns the + * inserted location of RUNNING_XACT record. Based on that, here + * returns the latest insert location for now. + */ + return GetInsertRecPtr(); Looking at the LogStandbySnapshot() that are using the output lsn, i.e: pg_log_standby_snapshot() BackgroundWriterMain() ReplicationSlotReserveWal() It looks ok to me to use GetInsertRecPtr(). But if we "really" want to produce a "new" WAL record, what about using LogLogicalMessage()? It could also be used for debugging purpose. Bonus point: it does not need wal_level to be set to logical. Thoughts? 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