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 P2v9EE4--F-9@rhyadav.dev
Whole thread
In response to PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation  (Jacky Nguyen <nktpro@gmail.com>)
Responses Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation
List pgsql-bugs
Hi Shihao,

On Fri, 2 Oct 2026, shihao zhong wrote:
> 0002 is your diff. It had no commit message, so I put one together
> from your mail. Please correct it if it is wrong.

Thanks for putting v3 together.  The message is right for master and
19.  On 17 and 18 the function that already does this is
heap_xlog_visible(), so in those versions the sentence would be:

  heap_xlog_visible() already initializes a VM page that was read as
  zeros.

0002 could also carry the same "Backpatch-through: 17" as 0001.

I ran my reproducer, which follows the same steps as 0003, against v3
on master and the nocfbot versions on 19, 18 and 17.  Unpatched
master and 17 fail to restart with the invalid pages PANIC.  With v3
the standby restarts cleanly on all four branches, in each of these
setups:

  - full_page_writes = off
  - full_page_writes = off, wal_consistency_checking = all
  - full_page_writes = on, wal_consistency_checking = all

0003 itself passes here too on all four branches, and fails on
master without 0001 and 0002.

Regards,
Rahul Yadav





pgsql-bugs by date:

Previous
From: shihao zhong
Date:
Subject: Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: Re: Streaming decoding fails with "unexpected table_index_fetch_tuple call during logical decoding" when a relation has a TOASTed conbin (follow-up to BUG #18641)