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 1vrIMJ-00DAck-2T for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Feb 2026 16:19:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrIMG-0000Gf-2d for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Feb 2026 16:19:00 +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 1vrIMG-0000GW-1I for pgsql-bugs@lists.postgresql.org; Sat, 14 Feb 2026 16:19:00 +0000 Received: from forwardcorp1a.mail.yandex.net ([178.154.239.72]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vrIMB-00000000cJN-1vQf for pgsql-bugs@lists.postgresql.org; Sat, 14 Feb 2026 16:18:59 +0000 Received: from mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net [IPv6:2a02:6b8:c2d:3530:0:640:eca4:0]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTPS id 9FE39C015F; Sat, 14 Feb 2026 19:18:51 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:c83::1:b]) by mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id nIZZlv1A68c0-sfrNe24v; Sat, 14 Feb 2026 19:18:51 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1771085931; bh=MbL+lTNBeMLEdHD2Yqa6o2JYhAldnNJypT6rlBbH7IA=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=lXR6jEHNGoQF45QDJtuYqr2XGaqWORkwTCUooVovid+H9fil3MKDH6LRj6AXBN+k4 sxsQ/7ETnCJLWPpW9aHX6wB87/MZW7xGYKM0L5ivUrnhPqCbXsAxxoNW/zkHSmzFLw UV7G+4xXUlkwNENA4ODw7KyXNZo5VOY0O27KfRmg= Authentication-Results: mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: 17.8 standby crashes during WAL replay from 17.5 primary: "could not access status of transaction" From: Andrey Borodin In-Reply-To: <349f9c82-3a8b-48ad-8cc4-fe81553793dd@iki.fi> Date: Sat, 14 Feb 2026 21:18:39 +0500 Cc: Sebastian Webber , pgsql-bugs@lists.postgresql.org, Andrey Borodin , =?utf-8?Q?=C3=81lvaro_Herrera?= , Dmitry Yurichev , Chao Li , Ivan Bykov , Kirill Reshke Content-Transfer-Encoding: quoted-printable Message-Id: References: <349f9c82-3a8b-48ad-8cc4-fe81553793dd@iki.fi> To: Heikki Linnakangas X-Mailer: Apple Mail (2.3864.300.41.1.7) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ouch... I remember this place. For some reason I thought endTruncOff is the end = of offsets. That would make sense here... Now I see it's just a new = oldest offset. > On 14 Feb 2026, at 16:42, Heikki Linnakangas wrote: >=20 > If we want to play it even more safe -- and I guess that's the right = thing to do for backpatching -- we could set latest_page_number = *temporarily* while we do the the truncation, and restore the old value = afterwards. As far as I can see, the only relevant usage of last_page_number is: /* * While we are holding the lock, make an important safety check: the * current endpoint page must not be eligible for removal. */ if (ctl->PagePrecedes(shared->latest_page_number, cutoffPage)) { LWLockRelease(shared->ControlLock); ereport(LOG, (errmsg("could not truncate directory \"%s\": apparent = wraparound", ctl->Dir))); return; } Perhaps, we also can bump latest_page_number forward? Best regards, Andrey Borodin.=