Re: pg_logical_slot_get_changes waits continously for a partial WAL record spanning across 2 pages
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Michael Paquier <michael@paquier.xyz>, 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-30T12:21:51Z
Lists: pgsql-hackers
Attachments
- 049_slot_get_changes_wait_continously_pg17.zip (application/x-zip-compressed)
- v3_PG14-0001-Fix-infinite-wait-when-reading-partially-written-.patch (application/octet-stream) patch v3-0001
- v3-0001-Fix-infinite-wait-when-reading-partially-written-.patch (application/octet-stream) patch v3-0001
- v3_PG17-0001-Fix-infinite-wait-when-reading-partially-written-.patch (application/octet-stream) patch v3-0001
On Mon, 30 Jun 2025 at 17:41, Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear Vignesh,
>
> > I was unable to reproduce the same test failure on the PG17 branch,
> > even after running the test around 500 times. However, on the master
> > branch, the failure consistently reproduces approximately once in
> > every 50 runs. I also noticed that while the buildfarm has reported
> > multiple failures for this test for the master branch, none of them
> > appear to be on the PG17 branch. I'm not yet sure why this discrepancy
> > exists.
>
> I was also not able to reproduce as-is. After analyzing bit more, I found on
> PG17, the workload cannot generate an FPI_FOR_HINT. The type of WAL record
> has longer length than the page there was a possibility that the WAL record
> could be flushed partially in HEAD. But in PG17 it could not happen so that
> OVERWRITE_CONTRECORD won't be appeared.
>
> I modified the test code like [1] and confirmed that the same stuck could happen
> on PG17. It generates a long record which can go across the page and can be
> flushed partially.
>
> [1]:
> ```
> --- a/src/test/recovery/t/046_checkpoint_logical_slot.pl
> +++ b/src/test/recovery/t/046_checkpoint_logical_slot.pl
> @@ -123,6 +123,10 @@ $node->safe_psql('postgres',
> $node->safe_psql('postgres',
> q{select injection_points_wakeup('checkpoint-before-old-wal-removal')});
>
> +# Generate a long WAL record
> +$node->safe_psql('postgres',
> + q{select pg_logical_emit_message(false, '', repeat('123456789', 1000))});
> ```
Thanks, Kuroda-san. I’ve prepared a similar test that doesn’t rely on
injection points. The issue reproduced consistently across all
branches up to PG13. You can use the attached
049_slot_get_changes_wait_continously_pg17.pl script (found in the
049_slot_get_changes_wait_continously_pg17.zip file) to verify this.
Just copy the script to src/test/recovery and run the test to observe
the problem.
The included patch addresses the issue. Use
v3_PG17-0001-Fix-infinite-wait-when-reading-partially-written-.patch
for PG17, PG16, and PG15, and
v3_PG14-0001-Fix-infinite-wait-when-reading-partially-written-.patch
for PG14 and PG13.
Regards,
Vignesh
Commits
-
Fix infinite wait when reading a partially written WAL record
- c9f4e7520603 17.6 landed
- 762f352ca4a6 13.22 landed
- bedfdb85b0a3 14.19 landed
- 9f270f48f3fe 15.14 landed
- b485e1c89a6d 16.10 landed
- d3917d8f13e7 19 (unreleased) landed
- 5449d5b7ae9c 18.0 landed
-
Improve the stability of the recovery test 047_checkpoint_physical_slot
- fd39c3cf2839 17.6 landed
- c71c702f067b 18.0 landed
- ccd945159361 19 (unreleased) landed
-
Improve recovery test 046_checkpoint_logical_slot
- 6aefde2a2db8 17.6 landed