Horton

Re: pg_logical_slot_get_changes waits continously for a partial WAL record spanning across 2 pages

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Amit Kapila <amit.kapila16@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-06-27T01:11:18Z
Lists: pgsql-hackers 
On Thu, Jun 26, 2025 at 09:40:05AM +0000, Hayato Kuroda (Fujitsu) wrote:
> I've spent time how we use the injection point to cause the same situation, which
> generates the OVERWRITE_CONTRECORD in-between the page, but it seems difficult.

Hmm.  I was wondering first about detecting a OVERWRITE_CONTRECORD
while looping in the loop of XLogDecodeNextRecord() with a
IS_INJECTION_POINT_ATTACHED(), then do a wait.  But this method means
that the injection point is linked to the fix we are trying to bundle
here because it would need to be placed between the two
ReadPageInternal() as we need to read the header first.  Usually I try
to place points so as they are generic enough, but that's a vague
philosophy.

> So... I have no idea to create deterministic reproducers, it is OK for me to use
> 046 test for the purpose.

Let's reuse 046 and call it a day.  It would not be the first
reproducer that fails on timeout if a problem arises.  The important
fact is to be informed about the failure, while keeping tests fast in
the "normal" cases.  We have a few tests like that already in the
tree, where a timeout is the best thing we can rely on when the code
fails its test.
--
Michael

Commits

  1. Fix infinite wait when reading a partially written WAL record

  2. Improve the stability of the recovery test 047_checkpoint_physical_slot

  3. Improve recovery test 046_checkpoint_logical_slot