Horton

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

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread View on postgr.es
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 'Michael Paquier' <michael@paquier.xyz>, vignesh C <vignesh21@gmail.com>
Cc: 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-26T09:40:05Z
Lists: pgsql-hackers 
> > Another reliable approach would be to make the
> > code wait before reading the record in the internal loop of
> > ReadPageInternal() with an injection point when we know that we have a
> > contrecord, but I'm not really excited about this prospect in
> > xlogreader.c which can be also used in the frontend.
> 
> Per my understanding an injection point must be added while flushing a WAL
> record,
> to emulate the incomplete WAL record issue. To confirm, how can it be used in
> ReadPageInternal()?

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.

XLogFlush()->XLogWrite() has a responsibility to flush WAL records, but it does not
write/flush per pages. It tries to write to pages as much as possible and
flushes the result at once. A corner case is when the segment is changed, but
this is not the same situation we observed the failure.

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

Best regards,
Hayato Kuroda
FUJITSU LIMITED

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