Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation - Mailing list pgsql-bugs

From rahul@rhyadav.dev
Subject Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation
Date
Msg-id P2s-NV0--F-9@rhyadav.dev
Whole thread
In response to Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation  (shihao zhong <zhong950419@gmail.com>)
Responses Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation
List 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

pgsql-bugs by date:

Previous
From: Vladimir Savin
Date:
Subject: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows
Next
From: Andrey Rachitskiy
Date:
Subject: Re: PG18: use-after-free in exec partition pruning after an EPQ recheck in LockRows