| From: | rahul(at)rhyadav(dot)dev |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, Nktpro <nktpro(at)gmail(dot)com>, Pgsql Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Subject: | Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation |
| Date: | 2026-10-01 15:07:40 |
| Message-ID: | P2s-NV0--F-9@rhyadav.dev |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On Mon, 28 Sep 2026, shihao zhong wrote:
> Melanie's v2-0002 in the VM clear thread [1] is the same change as
> candidate (a), and it fixes this report too.
I tested Melanie's v2 series as posted (0001-0003, which apply to
REL_19_STABLE) and candidate (a) on REL_18_STABLE, using the steps
from Shihao's test: full_page_writes = off and a plain standby
restart. Both were debug builds with assertions, and the fix works:
- Unpatched, 18 and 19 fail to restart with "WAL contains references
to invalid pages" after "page 0 of relation ..._vm does not exist"
for each table.
- Patched, the standby restarts and its VM forks end up truncated
again.
- On 18, reverting any one of the three RBM_ZERO_ON_ERROR changes
brings the PANIC back, so the test covers each of them.
However, with wal_consistency_checking = all on the primary, the
patched standby still fails to restart:
FATAL: invalid page pd_lower 0 pd_upper 0 pd_special 0
CONTEXT: WAL redo at 0/03A80068 for Heap/DELETE: ...;
blkref #1: rel 1663/5/16384, fork 2, blk 0 FPW
RBM_ZERO_ON_ERROR recreates the truncated VM page as all zeros.
verifyBackupPageConsistency() then masks it with heap_mask(), and
mask_unused_space() rejects a page with pd_lower 0.
heap_xlog_prune_freeze() and heap_xlog_multi_insert() already
initialize a VM page that was read as zeros, and doing the same at
the three VM clear sites fixes it. The attached diff applies on top
of v2 on REL_19_STABLE; with it, the standby restarts with and
without wal_consistency_checking. On 18, candidate (b) alone also
passes with wal_consistency_checking, since it never recreates the
page.
This only matters with wal_consistency_checking, but buildfarm
animals that use it could trip over Shihao's test once it's in.
Also, v2-0002 applies only on top of v2-0001 on REL_19_STABLE. On
master it doesn't apply after master-v2-0001, 18 needs its own
version (candidate (a) applies there as is), and in 17 the redo code
is in heapam.c.
[1] https://postgr.es/m/CAAKRu_bApoksLDb-HX0GYciU3uLWqA1JagntaV8GP0%3D%2BidehHw%40mail.gmail.com
Regards,
Rahul Yadav
| Attachment | Content-Type | Size |
|---|---|---|
| initialize-zeroed-vm-pages-on-v2.txt | text/plain | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Rachitskiy | 2026-10-01 16:15:32 | Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows |
| Previous Message | Vladimir Savin | 2026-10-01 14:27:54 | PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows |