Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 10 Feb 2026 09:34:35 +0900
From: Michael Paquier <michael@paquier.xyz>
To: ishanjoshi@live.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19396: Standby and DR site replication broken with PANIC:
 WAL contains references to invalid pages messge
Message-ID: <aYp9G02_B-sJdO6X@paquier.xyz>
References: <19396-eb33ed2e46a7a0e1@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="nKUcP+DJ3j04sZyE"
Content-Disposition: inline
In-Reply-To: <19396-eb33ed2e46a7a0e1@postgresql.org>
Archived-At: <https://www.postgresql.org/message-id/aYp9G02_B-sJdO6X%40paquier.xyz>
Precedence: bulk


--nKUcP+DJ3j04sZyE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 09, 2026 at 07:31:13AM +0000, PG Bug reporting form wrote:
> Primary db was not impacted, however standby node and DR site replication
> broken, I tried to reinit with latest backup + archive loading from
> pgbackrest backup but it fails with same error once the corrupt wal/archi=
ve
> file  applying the changes. I had to reinit with pgbasebackup with 40TB
> database which took about 45 hrs of time.
>=20
> Looks like some RACE condition happend to WAL file that generate the issu=
e.
> looks like potential bug of it.

Perhaps so.  However, it is basically impossible to determine if this
is actually an issue without more information.  Hence, one would need
more input about the workloads involved (concurrency included), the
pages touched, and the WAL patterns at least.  The best thing possible
would be a reproducible self-contained test case, of course, which
could be used to evaluate the versions impacted and the potential
solutions.  Race conditions like that with predefined WAL patterns
should be easy to reproduce with some injection points to force a
strict ordering of WAL record, particularly if this is a problem that
can be reproduced after a startup, where we just need to make sure
that a node is able to recover.

One thing that may matter, on top of my mind: does your backup setup
rely on the in-core incremental backups with some combined backups?
That could be a contributing factor, or not.
--
Michael

--nKUcP+DJ3j04sZyE
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmKfRsACgkQnvQgOdby
QH0CkA/7Bw9AUgwtPihqLxaKlbO7LxHWFKw7X25QcWD+NuCDiA4jYclVO5wnrzcn
BsjQF4JZN5QtAecQDz73EzzJ9aKH7LaCaXQavTihntJrneDR4gmYlLPC8JCQOzZu
reZisvScnXuIvkmBiT8U2vNJrN+OGZzRLRkcgcv6U2tytOIJBjeYKh1hLHtGUXkP
5hpb+lWAn56gPq06eHCwpbw1Ed0YtxPZmv2WPbyV68AJQeQCN7lhsrWbIhb1x9gr
C4PwKsD4fxPpK24ON0SfEdD05V1QTg6qp6eRtbsuieUSaY68Q6hVb7MAxJIXD/d+
cnamnkaTxAAtY98LSsAvp41+W+Xnfy8mfWeg7hSfxBQN0l2/rTKHZ9iqYeN6DylZ
hdYZFQ53pbXB9VYkNV8drKV6DMPT2td9RRhG+ToBFIQ3c/EoxeGWEX0ZvzydSUIH
nc230JqkXqSeDfnAcl+eZOj/Q5qJg1pTXy/C3oOF4cR3J6gRpx+Zlc+xrgpJhGsC
u1THBmjtEZJx16cQAoHhgurbuhPyv/cGk2h2pmRCRSqd4YZLZVONm69uRrucl9BY
CsnL2CRA+2AQhCfhqqzB+2XAKGBILsk1Lrzk15gupocmXG25CY7IMCt7PE/XowX/
ZltAnIgbbA1LD3bSTh1zM9eCNqR9ZTJXPwkhJWMT7tNYqClAEpE=
=CCeP
-----END PGP SIGNATURE-----

--nKUcP+DJ3j04sZyE--