Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish

On Wed, Sep 03, 2026 at 11:04:39AM +0900, Michael Paquier wrote:
> On Wed, Sep 02, 2026 at 06:13:26PM -0700, Bharath Rupireddy wrote:
>> Nice! Do you mind adding the reproducer as a TAP test for HEAD?
>
> I'm assuming that it should be possible to use an injection points
> based on the fact that we would be up and running for the inserts.

Thanks, both. Attached is v2: 0001 is the fix, unchanged from v1, and
0002 adds the reproducer as a TAP test on HEAD.

The test adds a small module, src/test/modules/test_walwriter, with one
C function that requests a segment switch and then stores the resulting
insert position in asyncXactLSN. After a switch that position is just
past the new segment's long page header, beyond the end of generated
WAL, so the walwriter's next cycle requests a flush past the end of
generated WAL -- the same shape as the production request.

I did look at injection points first, but there is no INJECTION_POINT()
in this path, and what the reproducer needs is a bogus value stored
into asyncXactLSN rather than a backend stopped at a particular point,
which would require a custom callback and hence a test module anyway.
A plain test module also keeps the test runnable in builds without
injection point support. The timing side needs no help: with the
test's wal_writer_flush_after = 0, XLogSetAsyncXactLSN() wakes the
walwriter, which picks the value up on its next cycle, so the test
just waits for the existing "request to flush past end of generated
WAL" message to show up in the log.

After that message, the test checks that the advertised flush position
is still below the bogus request, that no child process was terminated,
and that normal WAL activity afterwards gets past that position.

On unpatched HEAD the test fails in both assert and production builds:
XLogWrite() hits its "xlog write request ... is past end of log" PANIC
and the walwriter's crash takes the server down (TAP clusters run with
restart_after_crash = off). (Which sanity check fires first depends
on the WAL buffer state; with 1MB segments I had seen the
Insert >= Write assertion instead.) With 0001 applied, both build
types pass the test.

Regards,
Paul