Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCXFi-00000003qfa-2WP7 for pgsql-bugs@arkaria.postgresql.org; Fri, 02 Oct 2026 07:00:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xCXFh-0000000AiTD-2YZ1 for pgsql-bugs@arkaria.postgresql.org; Fri, 02 Oct 2026 07:00:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCXFh-0000000AiT4-0esf for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 07:00:17 +0000 Received: from mail.w14.tutanota.de ([185.205.69.214]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCXFf-00000002P0N-07lT for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 07:00:16 +0000 Received: from tutadb.w10.tutanota.de (w10.api.tuta.com [IPv6:fd:ac::d:10]) by mail.w14.tutanota.de (Postfix) with ESMTP id 0B35F18E4CA43 for ; Fri, 2 Oct 2026 09:00:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1790924413; s=s1; d=rhyadav.dev; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=iee8yMVp2XWO/OFeto8Xq+U3+SU78BgCZid6nCe5CxY=; b=D6utEgTjKDNjLpqwIkd158wHnqjZxr9sJaaeBR5Ug45FIx4H/7njeiyRfmTZG4Z2 xEMYE9yFXaZjDKy7dAqIepXc9LzHxfjwZmRV0XUwOZ4OYbFLUkKAaI9XUATE0/P+sOr 6e2Fj2Dan6+ln7GRWfofhBy8vZlK+xuWJEQ9nL0fKHqZHYPjMCZdVBKoz9vizQfiptN 5Chk8aim5W0wU1fo+9yaMUFEOoyq3fmExuiVIxKqOujtYptZm3xwNFLgyO+/lY/X9Eu EzIKtHE5vi/iO/pkdRWQbpJJ1JzWC8xHyw0+Zr1wEkD3TeisOcWMWUERay3PZs+irpK NHRMxC1LbQ== Date: Fri, 2 Oct 2026 09:00:13 +0200 (CEST) From: rahul@rhyadav.dev To: shihao zhong Cc: Kirill Reshke , Nktpro , Pgsql Bugs , Melanie Plageman Message-ID: In-Reply-To: References: Subject: Re: PostgreSQL 18.6/17.11: standby PANIC on restart after VM truncation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Feedback-ID: 01f8c5108c48fea26a092a077590a8fcdbfcdbb733bc38e3db5db9540fc242b99227bb05256e786b1fc713cdb05f073377d63f8aec9e32cbf77d26f42c5d89118b:TurnOnPrivacy!:tutamail List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.=C2=A0 The message is right for master and 19.=C2=A0 On 17 and 18 the function that already does this is heap_xlog_visible(), so in those versions the sentence would be: =C2=A0 heap_xlog_visible() already initializes a VM page that was read as =C2=A0 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.=C2=A0 Unpatched master and 17 fail to restart with the invalid pages PANIC.=C2=A0 With v3 the standby restarts cleanly on all four branches, in each of these setups: =C2=A0 - full_page_writes =3D off =C2=A0 - full_page_writes =3D off, wal_consistency_checking =3D all =C2=A0 - full_page_writes =3D on, wal_consistency_checking =3D all 0003 itself passes here too on all four branches, and fails on master without 0001 and 0002. Regards, Rahul Yadav