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 1w3a4v-001MdX-0h for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Mar 2026 13:39:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w3a4t-006HqA-2D for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Mar 2026 13:39:52 +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 1w3a4t-006Hq2-0t for pgsql-hackers@lists.postgresql.org; Fri, 20 Mar 2026 13:39:51 +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 1w3a4p-00000000AoT-2SOU for pgsql-hackers@postgresql.org; Fri, 20 Mar 2026 13:39:50 +0000 Received: from mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:3a87:0:640:845c:0]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTPS id 82C37C01FD; Fri, 20 Mar 2026 16:39:43 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:18::1:2d]) by mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id gdPoAW2AeSw0-kWp8yNff; Fri, 20 Mar 2026 16:39:43 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1774013983; bh=zODc9gF72Q/5adf1qQ4TM6XLtUzFYITs2dBtPwqnPrc=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=m7ukk9FIe88x84Ge5zyMjOTokQuMzWcvrFCGHVxYY4h1DMPRKiGcMX8IFoOiywr9G FMD4z6wfNjQdMp/cQiJ0ynGcgCpoRD47qXSbOc9VioOgxG8GbLQk1W5JtZeemdyJxI U3ldtGDNRNBvgBE8/EPr5vIg3PxnHuCiq90sN86E= Authentication-Results: mail-nwsmtp-smtp-corp-main-69.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.400.21\)) Subject: Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery From: Andrey Borodin In-Reply-To: <452355ef-7c20-4d96-88a2-8fbb49737dc9@iki.fi> Date: Fri, 20 Mar 2026 16:39:32 +0300 Cc: =?utf-8?B?IuauteWdpOS7gSjliLvpn6cpIg==?= , pgsql-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <18a40051-abc2-4fc2-8dcc-4dc39aa3e79e@iki.fi> <452355ef-7c20-4d96-88a2-8fbb49737dc9@iki.fi> To: Heikki Linnakangas X-Mailer: Apple Mail (2.3864.400.21) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 20 Mar 2026, at 16:19, Heikki Linnakangas wrote: >=20 > Hmm, after startup, before we have zeroed any pages, it still works = though. So I think my patch works, but it means that tracking the latest = page we have zeroed is not merely an optimization to avoid excessive = SimpleLruDoesPhysicalPageExist() calls, it's needed for correctness. = Need to adjust the comments for that. If we are sure buffers have no this page we can detect it via FS. Otherwise... nothing bad can happen, actually. We might get false = positive and zero the page once more. If we got init_needed=3D=3Dfalse, maybe cache it for this page and set = last_initialized_offsets_page =3D pageno? Or, perhaps, XLOG_MULTIXACT_ZERO_OFF_PAGE will do it for us anyway, but = a bit later. Best regards, Andrey Borodin.=