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.96) (envelope-from ) id 1vpfGq-00D4p6-0y for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Feb 2026 04:22:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpfGn-00Djij-2O for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Feb 2026 04:22:37 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vpfGn-00DjiY-0W for pgsql-bugs@lists.postgresql.org; Tue, 10 Feb 2026 04:22:37 +0000 Received: from mail-eastusazolkn190120001.outbound.protection.outlook.com ([2a01:111:f403:d100::1] helo=BL0PR03CU003.outbound.protection.outlook.com) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vpfGk-00000001NSH-1g87 for pgsql-bugs@lists.postgresql.org; Tue, 10 Feb 2026 04:22:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=F3GLGEEC1Zvuy0r9S8URj3EKvPcjK4+ic2IAULq8SheYldcn8SFxdoAD5U+p85ggF458ThydX4eyPyc5Bcyi5Rr2egE87JZVI5XljBfEDELJX9afpPns4kTkboE6v4V0qNwldqmSBShuxl/r9aQdCM/kwII7glCQavMwYobwG8CJziWyk0Q2niWBlh1rmZiFBJ349YlRXsYaD6KjSB+El4tV3KEQrvUUFN0lJHfwNQsTHuYnl78ENAC6KKGSkO1djwwyFdyLi4ME3RQfuHUN4NxKpMfj72H6WGSHOjQNHyPMVvzh3BXdGcmEyxteWpnfBb8sK50tDj9ZvQcR79XIZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iwjXdTodsmPwEcw6SwsQ6597ShJDjJ6asuh+v8vwBSc=; b=QB/6W/ucOdu7gyXmr+feZqrxbgsahxbo7wwYavcUENscpu8SNEAyU0KhTKs9O8YgC8Q+1eYw6qhIDboxIwfFq4NsVDcWT/111A3MISJZpazev1u5/oZ1gcKIhFUCGrYmo0ymqp0gccUkOGz9MqyVKyuKr+dcS3MeigjzCqg7s3EI3JBzSJLffuaslOmNZTpXhvHh6BOOHmDllH/TZXBRiaLOrsoefL02IYCEy/zDtkZf72AK8Y0kT4Ytqd+F3/DDzBs9fAWAkAehnD8YjGlcZPM1GQ9fvxT4qiNqCdu7zTdfnKfzrpbrSrGKel9WCh1JFIMhCbea8/Qpt69cTT2mPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iwjXdTodsmPwEcw6SwsQ6597ShJDjJ6asuh+v8vwBSc=; b=m8SVlNV56ECELcSISj7mgujufoYyZnYYyaAEnB/jlVmFyh+em3D8fej6UhKxnVaw/wpJDZYnzebRg1C6aRquEGLX8/QB0T8SY7pJ5vYpWYoIa36HTPKPPbWXc2ClsXI9ycMqbGjKW4qYLJDEl9Z7bDKhcWMntKTGVswuWuY8RJcLNbXs2tXShKmGr8iXgkrblR35EvVPkLQXlT+yoajnDoavPGkt8ieQlcxVbmZbPrzUe3I4Hvhd+4fxCUS/pjqUKVNcqq1lIZLGWytR+gJZW/SC881mLcYC9fGxG2B0gFKtFDeP9W85bJYiwyUiFoarJKkL/SqNPP2XQwq+qQidmg== Received: from EA2PR84MB3780.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:303:25b::18) by DM4PR84MB1975.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:8:4e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9587.18; Tue, 10 Feb 2026 04:22:30 +0000 Received: from EA2PR84MB3780.NAMPRD84.PROD.OUTLOOK.COM ([fe80::ff1d:2167:ca2d:23db]) by EA2PR84MB3780.NAMPRD84.PROD.OUTLOOK.COM ([fe80::ff1d:2167:ca2d:23db%4]) with mapi id 15.20.9587.013; Tue, 10 Feb 2026 04:22:29 +0000 From: Ishan joshi To: Michael Paquier , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #19396: Standby and DR site replication broken with PANIC: WAL contains references to invalid pages messge Thread-Topic: BUG #19396: Standby and DR site replication broken with PANIC: WAL contains references to invalid pages messge Thread-Index: AQHcmiUNo9adyuAoNEWgT7l0ucybv7V7TXFH Date: Tue, 10 Feb 2026 04:22:28 +0000 Message-ID: References: <19396-eb33ed2e46a7a0e1@postgresql.org> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: EA2PR84MB3780:EE_|DM4PR84MB1975:EE_ x-ms-office365-filtering-correlation-id: 3a35ad91-606e-4c07-d565-08de685c0024 x-microsoft-antispam: BCL:0;ARA:14566002|8062599012|39105399006|19110799012|12121999013|15030799006|15080799012|31061999003|461199028|8060799015|40105399003|3412199025|440099028|10035399007|102099032|14065499006|30101999003; x-microsoft-antispam-message-info: =?iso-8859-1?Q?9OyIsbcB2u7COeVXLpm/vfwxy2m5/bhIXsQIjV1/FSO4fdYAR1Y+09290L?= =?iso-8859-1?Q?AMjhDoAo3kYWoEGxX96NnjpgeNH379IyuGbjMjw1eGjH7TJMEDsswQFk2O?= =?iso-8859-1?Q?bLwF+LPhSx4UWiFvaDn9ADqQ5aH3b1ldRG8ZOCvh9Ky4tCQrh/Th7eUg9e?= =?iso-8859-1?Q?036KkDOLpBi4iNawp6bM/UCMW/6PJrMvHCe44+E1BQaiprJveWVuOaV5fm?= =?iso-8859-1?Q?axOSFv+4smroVUtfNrqX9w2yWAX4DuHhg+K5QmjdQb2Wo0lIWKCWBHtmd3?= =?iso-8859-1?Q?MaA3wmAqOorRCyFASeZPjBYANrD2/WExaZVZd+L6dsOMuFvy5hPzk4vNuJ?= =?iso-8859-1?Q?Ouws2Zi/RmpBQN8QysnCqcfm+6Dor/IybvNnosFQRI+uK0YoQYD9NOMjkC?= =?iso-8859-1?Q?AdZY+oTXG28bS9xLjDwJLYSFW+EE1/WVk+jCCBOWcgeZ26H6dakfqM9idZ?= =?iso-8859-1?Q?FjF7Z01ZOT6oAHRDvwhfl5Dwz/jZYILY29yfUl8vy56n5iHcMVFUL0rqIG?= =?iso-8859-1?Q?exHQBATEnEzdxpzGPK8ByTUz6ApTUZvCCRL9/DUcpQsmbdnwLTrhxoLrDZ?= =?iso-8859-1?Q?+ii8lv8wZxIbNOzkh4GhVsngpJr3+v/6dMpNHNcw2IitbYmqjv0/cfUDXd?= =?iso-8859-1?Q?SzvKzmy92xGR7vpYwEZjswLa0s56goZPGorNq9jxfjiMREb+TRWJ4Dt+iP?= =?iso-8859-1?Q?fVbX/BI+r5aUzaei36c4Hf64yXSD9J+Bj0VXAfyYZrZDWwmKtJeoGeAwMO?= =?iso-8859-1?Q?E7HXAH8h90I59XCo1AK9lMiuWW5h+OLZ2whIh6E6w8N7AlCSeAnxzpMYX1?= =?iso-8859-1?Q?oDSt18/6OI/asOF5hzI+W8XYRnfG1EXFlk9x42XZCuCyTEQuRJejGqTIQP?= =?iso-8859-1?Q?bEwA90LwPdivxJW5YcLf4mzN6lUT1A4eRa3Ncr9+NcQGXDG78NbezEjeRG?= =?iso-8859-1?Q?wZ4hrBlNQ2f5PFETq0KoxGTR5hcIp4yMcY/APUi3gc2Hb/OcLgk/PeXV1B?= =?iso-8859-1?Q?5e4vgVPt1E0Pjf+9vLS7L2BEVnpuol01rDPiV424dxVFrI0yUqYHWuRS7s?= =?iso-8859-1?Q?SSBMftxZQezX1e6255BGETYBQp4k8083t6fMoetFTENf7T9M6/ys0n5ktb?= =?iso-8859-1?Q?9NzbNFY5GYxiXG3mXDLsdD7jGv5AkzdjdtECqu5Ps+K6yLwFuieEVg99jg?= =?iso-8859-1?Q?wneZPKrEYeCvnhK7kzJnI+tw+YqgLjK514xAPEXsxfZNwpwrdHEAvc5Ux0?= =?iso-8859-1?Q?IqLxkEqTZTxLylQEGMk9bu8AmUrAJMtd19ptB/e4Gw6wBvpZLd/me3YHnn?= =?iso-8859-1?Q?/I/caXnQ25OrRwSE6jTcFXIIfJCYH9aHKKgj8vtfkolLXIxqo7IbPYViLU?= =?iso-8859-1?Q?T8dd+Y/RCd?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?EnWQ6/nFqyK+cs091k+qXoFSieYJEvB00uH0kOE8Ov4fayjNSPTJVKzsrX?= =?iso-8859-1?Q?0pprxXLUH+IcdQb3xIKAyBGthIg9JWcXkDhF0Anry/8nvVotqfMgeypWAq?= =?iso-8859-1?Q?vR0Fr9QvoUAH4MzrVou65qDmPOxaG5jkGHAS2GirQHkZLPRqNCmO4ClaS1?= =?iso-8859-1?Q?nweBvW4j/4dOb8dqWgSXTHfDOlYrs8aGR1fs+HvSN+rvDh6qTyz80c/nRv?= =?iso-8859-1?Q?S5fdnfRFvFeXTCj47ng8RcihHUEse32839mBUjAVckpX7j42Cshk46+MDS?= =?iso-8859-1?Q?nXuVEphUbAG9IveSqsfUsL/m/YMznYTFaXWCJXYFWYMA7B7li77AiCHcyW?= =?iso-8859-1?Q?fq6yfZrajgDjAOWvE/TuiziohjFz9rZ04Ztw12pvUIlI2thrSJEPke8z5M?= =?iso-8859-1?Q?ckLw/YFRMxPck4Xh9ytDN8EjvQOjb3AdGYxUr5AE6E1AVCQxTB0L/1hTDt?= =?iso-8859-1?Q?RcwMM5v2PEbKUlOHb1Ttnz8aWEFR1Yy5E260w05+R9lSnpLBBHtlk3C2jc?= =?iso-8859-1?Q?E/wnNeKNRVVlr152B+RmDEA8AsYCQ0xivTOpA65+995XOtGkBk3b7S1iMj?= =?iso-8859-1?Q?PaF1QBc4RtzyWiDPyXSLLzTtGykWpQtEn3HAUrQvvadotKkpMfzWUteCDd?= =?iso-8859-1?Q?8TNkQKSmm2Vh6oKx8ms1Q5Dof6vmNU/gugdeuK3jiB5jHZumZNR6/+UsZv?= =?iso-8859-1?Q?hTwWMPKYpNlMmieIUZmsHbc/hZZAkr8pzOfHFfN+7ApFll6HlTOVEfvHAS?= =?iso-8859-1?Q?DUyXBJ5WlbBLCt0yHkaX1Q6lDG/cVSnLl6HJpqBlsMVxjouQ8hgjjZZznf?= =?iso-8859-1?Q?a2HGwaTmiB/5KmrnzKbDhexQTOGRBLr69hdMtvavodikpDal6bVsz7TRAr?= =?iso-8859-1?Q?3N5iC39jN1yPZMoLJy04P8Y8E1jsfee7E6ZmBf1g5R3i4Xv0uaWkIXwE2A?= =?iso-8859-1?Q?QOfUArR5LxjW8kVk6tTZ/ORvapCk27X7BgFMMhrBkq7EhL55JRuMxsGl3t?= =?iso-8859-1?Q?ErNYuYHOpWQtyO25L2evuaGtEX3s7Ur1f8EN5fZrpeX2UB2pmnMih0qQ81?= =?iso-8859-1?Q?TXSuctKN9Px6P1WYNahAHRvslCxcnyaMwM+xkCrr5x71nqZ6eOyVfktyxQ?= =?iso-8859-1?Q?EislpC8rm9gUisKjwCjo3QDch/UEgLQ9p/AAmZqQamjQcw6W5FPL0yITai?= =?iso-8859-1?Q?hdjt2T6Fb+kGUhbHAvlrBc1KiiDFOz2sb9mlMBr52WdM+n1/NZGL9NuBnO?= =?iso-8859-1?Q?lYcMetegC/V6qYjjpLVzhxnsMMq/IHH9qEgF+Dj9E02oHznmlchNwnRjHX?= =?iso-8859-1?Q?cHGTgX5lq91hohOZPFj+CNgpCZJrNjyV1H//V9tpli80BkAOoEzC/CLqDQ?= =?iso-8859-1?Q?VzEWnIRmZyRwC271XVUCc2W9gyZinpBIHMOtNygZ3xJMPIW3/Iu3I=3D?= Content-Type: multipart/alternative; boundary="_000_EA2PR84MB3780E8BAE3FFA3C4988059F4A962AEA2PR84MB3780NAMP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-9412-4-msonline-outlook-a21eb.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: EA2PR84MB3780.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 3a35ad91-606e-4c07-d565-08de685c0024 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2026 04:22:28.1804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR84MB1975 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_EA2PR84MB3780E8BAE3FFA3C4988059F4A962AEA2PR84MB3780NAMP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, As have pgbackrest backup configure that used to take incremental backup. s= omehow, we tried to recover standby node with latest incremental backup, it= was restored well but getting failed at the time of restoring archive file= at same point where the actual issue was occurred. we are running this in production for 6 months now and this is the first ti= me we have face this issue. we never face such issue in performance testing= environment where such kind of session/transcation executed. Here looks li= ke wal file creation itself having issues as it trying to create table but= it got failed the transaction with broken pipe error, this makes the trans= action got rollback and not created table in production but WAL file missed= to log the create table and rollback things that makes the some dml operat= ion on that table got executed while reply on standby and it got failed in = standby as well as in DR site. as the WAL itself having wrong transaction sequence, archive file also havi= ng the same issue and that is makes recovery from backup also got failed. ERROR while recovering from backup 2026-02-06 12:28:44.069 P00 INFO: archive-get command begin 2.55.1: [0000= 002E000184F300000007, pg_wal/RECOVERYXLOG] --archive-async --archive-timeou= t=3D600 --compress-level-network=3D3 --exec-id=3D33803-b2d6a506 --log-level= -console=3Dinfo --log-level-file=3Ddetail --pg2-host=3Dpg-patroni --pg1-pat= h=3D/var/lib/pgsql/data/postgresql_node1/ --pg2-path=3D/var/lib/pgsql/data/= postgresql_node2/ --process-max=3D15 --repo1-path=3D/var/lib/pgbackrest --r= epo1-s3-bucket=3Dprdbucket --repo1-s3-endpoint=3Dhttps://10.150.13.38:5443 = --repo1-s3-key=3D --repo1-s3-key-secret=3D --repo1-s3-r= egion=3D --repo1-s3-uri-style=3Dpath --no-repo1-storage-verify= -tls --repo1-type=3Ds3 --spool-path=3D/var/lib/pgsql/data/pgbackrest --stan= za=3Dpatroni 2026-02-06 12:28:44.069 P00 INFO: found 0000002E000184F300000007 in the a= rchive asynchronously 2026-02-06 12:28:44.073 P00 INFO: archive-get command end: completed succ= essfully (6ms) 2026-02-06 19:28:44.076 +07 [18415]LOG: restored log file "0000002E0001= 84F300000007" from archive 2026-02-06 12:28:44,438 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0) 2026-02-06 12:28:45,425 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0) 2026-02-06 12:28:46,428 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0) 2026-02-06 19:28:46.567 +07 [18415]WARNING: page 25329 of relation base= /33195/410203483 does not exist 2026-02-06 19:28:46.567 +07 [18415]CONTEXT: WAL redo at 184F3/F248B6F0 = for Heap/LOCK: xmax: 2818115117, off: 35, infobits: [LOCK_ONLY, EXCL_LOCK],= flags: 0x00; blkref #0: rel 1663/33195/410203483, blk 25329 2026-02-06 19:28:46.567 +07 [18415]PANIC: WAL contains references to in= valid pages 2026-02-06 19:28:46.567 +07 [18415]CONTEXT: WAL redo at 184F3/F248B6F0 = for Heap/LOCK: xmax: 2818115117, off: 35, infobits: [LOCK_ONLY, EXCL_LOCK],= flags: 0x00; blkref #0: rel 1663/33195/410203483, blk 25329 2026-02-06 19:28:46.669 +07 [18407]LOG: startup process (PID 18415) was= terminated by signal 6: Aborted 2026-02-06 19:28:46.670 +07 [18407]LOG: terminating any other active se= rver processes 2026-02-06 19:28:46.797 +07 [18407]LOG: shutting down due to startup pr= ocess failure 2026-02-06 19:28:46.978 +07 [18407]LOG: database system is shut down I am not sure if we can reproduce such scenario easly as it is very strange= and rare scenario to validate. If you have any test scneario then pls sugg= est I can test it in local env. Please suggest if any more information requires. Thanks & Regards, Ishan Joshi ________________________________ From: Michael Paquier Sent: Tuesday, February 10, 2026 06:04 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 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. > > 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 --_000_EA2PR84MB3780E8BAE3FFA3C4988059F4A962AEA2PR84MB3780NAMP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Michael,

As have pgbackrest backup configure that used to take incremental backup. s= omehow, we tried to recover standby node with latest incremental backup, it= was restored well but getting failed at the time of restoring archive file= at same point where the actual issue was occurred.

we are running this in production for 6 months now and this is the first ti= me we have face this issue. we never face such issue in performance testing= environment where such kind of session/transcation executed. Here looks li= ke wal file creation itself having issues as it trying to create table  but it got failed the transactio= n with broken pipe error, this makes the transaction got rollback and not c= reated table in production but WAL file missed to log the create table and = rollback things that makes the some dml operation on that table got executed while reply on standby and it got fai= led in standby as well as in DR site. 

as the WAL itself having wrong transaction sequence, archive file also havi= ng the same issue and that is makes recovery from backup also got failed.
ERROR while recovering from backup

2026-02-06 12:28:44.069 P00   INFO: archive-get command begin 2.55.1: = [0000002E000184F300000007, pg_wal/RECOVERYXLOG] --archive-async --archive-t= imeout=3D600 --compress-level-network=3D3 --exec-id=3D33803-b2d6a506 --log-= level-console=3Dinfo --log-level-file=3Ddetail --pg2-host=3Dpg-patroni --pg1-path=3D/var/lib/pgsql/data/postgresql_node1/= --pg2-path=3D/var/lib/pgsql/data/postgresql_node2/ --process-max=3D15 --re= po1-path=3D/var/lib/pgbackrest --repo1-s3-bucket=3Dprdbucket --repo1-s3-end= point=3Dhttps://10.150.13.38:5443 --repo1-s3-key=3D<redacted> --repo1-s3-key-secret=3D<redacted> --repo1-s3-region=3D<region_na= me> --repo1-s3-uri-style=3Dpath --no-repo1-storage-verify-tls --repo1-ty= pe=3Ds3 --spool-path=3D/var/lib/pgsql/data/pgbackrest --stanza=3Dpatroni
2026-02-06 12:28:44.069 P00   INFO: found 0000002E000184F300000007 in = the archive asynchronously
2026-02-06 12:28:44.073 P00   INFO: archive-get command end: completed= successfully (6ms)
2026-02-06 19:28:44.076 +07    [18415]LOG:  restored log fil= e "0000002E000184F300000007" from archive
2026-02-06 12:28:44,438 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0)
2026-02-06 12:28:45,425 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0)
2026-02-06 12:28:46,428 INFO: no action. I am (pg-patroni-node1-0), a secon= dary, and following a leader (pg-patroni-node2-0)
2026-02-06 19:28:46.567 +07    [18415]WARNING:  page 25329 o= f relation base/33195/410203483 does not exist
2026-02-06 19:28:46.567 +07    [18415]CONTEXT:  WAL redo at = 184F3/F248B6F0 for Heap/LOCK: xmax: 2818115117, off: 35, infobits: [LOCK_ON= LY, EXCL_LOCK], flags: 0x00; blkref #0: rel 1663/33195/410203483, blk 25329=
2026-02-06 19:28:46.567 +07    [18415]PANIC:  WAL contains r= eferences to invalid pages
2026-02-06 19:28:46.567 +07    [18415]CONTEXT:  WAL redo at = 184F3/F248B6F0 for Heap/LOCK: xmax: 2818115117, off: 35, infobits: [LOCK_ON= LY, EXCL_LOCK], flags: 0x00; blkref #0: rel 1663/33195/410203483, blk 25329=
2026-02-06 19:28:46.669 +07    [18407]LOG:  startup process = (PID 18415) was terminated by signal 6: Aborted
2026-02-06 19:28:46.670 +07    [18407]LOG:  terminating any = other active server processes
2026-02-06 19:28:46.797 +07    [18407]LOG:  shutting down du= e to startup process failure
2026-02-06 19:28:46.978 +07    [18407]LOG:  database system = is shut down

I am not sure if we can reproduce such scenario easly as it is very strange= and rare scenario to validate. If you have any test scneario then pls sugg= est I can test it in local env.
Please suggest if any more information requires.

Thanks & Regards,
Ishan Joshi

From: Michael Paquier
Sent: Tuesday, February 10, 2026 06:04
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

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

Perhaps so.  However, it is basically impossible to determine if this<= br> is actually an issue without more information.  Hence, one would need<= br> 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
--_000_EA2PR84MB3780E8BAE3FFA3C4988059F4A962AEA2PR84MB3780NAMP_--