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

From: Paul Kim <mok03127(at)gmail(dot)com>
To: bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish
Date: 2026-10-13 09:51:05
Message-ID: 179188506544.48047.5495756894805379265@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

A correction to what I wrote about 15 and 16: they crash too.

In my runs on those branches the padding was done with async commits,
and before 17 every async commit wakes the walwriter. After each flush
the walwriter initializes WAL buffers ahead, so the page at the
boundary was already initialized by the time of the switch. 17 wakes
the walwriter much less often (1f395354d87), which is why I only saw
the PANIC there.

If nothing wakes the walwriter between the padding and the switch, for
example when both run in one transaction, REL_15 and REL_16 PANIC the
same way, 4 out of 4 on each. And my original test PANICs on
1f395354d87 itself, but not with that commit reverted.

So the case for back-patching is the same on all branches.

Regards,
Paul Kim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message solai v 2026-10-13 09:51:54 Re: [PATCH] pg_combinebackup: make the OID range check in parse_oid() effective
Previous Message shveta malik 2026-10-13 09:41:49 Re: Proposal: Conflict log history table for Logical Replication