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 1w3dIY-001PPl-0k for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Mar 2026 17:06:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w3dIW-007U26-2R for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Mar 2026 17:06:09 +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.96) (envelope-from ) id 1w3dIW-007U1y-19 for pgsql-hackers@lists.postgresql.org; Fri, 20 Mar 2026 17:06:08 +0000 Received: from forwardcorp1d.mail.yandex.net ([178.154.239.200]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w3dIT-00000000DA6-3nGQ for pgsql-hackers@postgresql.org; Fri, 20 Mar 2026 17:06:08 +0000 Received: from mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:94a9:0:640:a3fa:0]) by forwardcorp1d.mail.yandex.net (Yandex) with ESMTPS id 8A4DE807A9; Fri, 20 Mar 2026 20:06:04 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:757::1:b]) by mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id 36TnDh2AX0U0-w00oJzea; Fri, 20 Mar 2026 20:06:04 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1774026364; bh=cGHg6Ysij5pfaDrgleys0wn0NJHYnz1K3f4y3FGrgh8=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=Aao3+Sg1wCXIWKmhCAkEUPhCDWf5tY07bEgKEhzL5uBx5b4EBcs/1q7Jvew6N+Js7 7PtJMLmen7FM++CG90Phuz3/hgDMEpN/5eGTLFClLKD1OdzonzNkbzpNBZfWRq+BHm mg8QbCXe7Y/CWOCJL783PMCm57IJwmMwGGHtpg0s= Authentication-Results: mail-nwsmtp-smtp-corp-main-68.klg.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: <5b7f0a04-4a60-44bb-9d2c-8917af0b10fa@iki.fi> Date: Fri, 20 Mar 2026 20:05:53 +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> <5b7f0a04-4a60-44bb-9d2c-8917af0b10fa@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 18:14, Heikki Linnakangas wrote: >=20 > Zeroing the page again is dangerous because the CREATE_ID records can = be out of order. The page might already contain some later multixids, = and zeroing will overwrite them. I see only cases when it's not a problem: we zeroed page, did not flush = it, thus did not extend the file, crashed, tested FS, zeroed page once = more, overwrote again by replaying WAL, no big deal. We should never zero a page with offsets, that will not be replayed by = WAL. If the page was persisted, even partially, we will read it from disk = without zeroing out. Best regards, Andrey Borodin.=