Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation

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-02 07:00:13
Message-ID: P2v9EE4--F-9@rhyadav.dev
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-10-02 07:33:09 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)
Previous Message shihao zhong 2026-10-02 05:15:50 Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation