Re: Fix 035_standby_logical_decoding.pl race conditions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix 035_standby_logical_decoding.pl race conditions
Date
Msg-id Z_c0RJtQ56fVifYT@paquier.xyz
Whole thread Raw
In response to Re: Fix 035_standby_logical_decoding.pl race conditions  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Apr 09, 2025 at 12:07:31PM +0530, Amit Kapila wrote:
> On Wed, Apr 9, 2025 at 11:24 AM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> I can't think of a good reason to have this DEBUG1 as there is no
> predictability of it getting generated even with tests using an
> injection point. OTOH, I don't have any objections to it if you would
> like to proceed with this.

The non-predictability of the event is my reason, as it can be useful
to know this information when grabbing for specific patterns in the
logs between failed and successful run differences.  In short, I'd
like to think that we are OK here, still this information is free to
have and it could be useful if we still have problems.  A custom
message WAL record is overdoing in it a bit, IMO, an elog() with the
LSN returned should be enough.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c
Next
From: David Rowley
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions