| 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
| 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 |