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 1vyELp-00HYIg-1W for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 19:27:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vyELn-000xeS-2W for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 19:27:12 +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 1vyELm-000xeJ-29 for pgsql-hackers@lists.postgresql.org; Thu, 05 Mar 2026 19:27:11 +0000 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vyELk-00000000blL-45ew for pgsql-hackers@postgresql.org; Thu, 05 Mar 2026 19:27:10 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 4141F1D00199; Thu, 5 Mar 2026 14:27:07 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 05 Mar 2026 14:27:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1772738827; x=1772825227; bh=edcVCA2fV9 BfXk4CEYvlLA0Lu9HUHUVm8qLA7U1oukM=; b=BfGYexR53VfxCT1cEYU5N493DY Eu5sxGWxbwOXaIrZfcUN2iDg8koyQUHcvYli6r7LMFyr1wFtLDa0iThWG9/LvT2m atjQhpjfxPcDO/I3Ohay0DbI/IBlM8sTCj6xgcYKdrE+keacypcSv+6vN2aoR7kb ji6op+igkckLcVFWuj5xKzxni0Y5U0KIrEgmXlcqMXUqAEiTjty6go5VJgty7hH2 /TXBUulMcJFQatswTQEkMJbOzWJG1hqlWqyaNntDM79c1kbGTBzTfeeB0SCeMs2d ODmM/AiE6odAVTy18puowPjzs4KBhEnLU6OyT7Rco/G0gfnkYiKFIBJ6nViA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1772738827; x=1772825227; bh=edcVCA2fV9BfXk4CEYvlLA0Lu9HUHUVm8qL A7U1oukM=; b=icxebma5oiFLJ0CNX9aYpAssyQ6AvuUZAOk3s0LQ7U9KRFCIO+I V6UFHQ9HeVvypquT3eeNy2eYNBYZxe91DTtsWGGSO93AIMFI0FPqGPLJ9WQoUcRT glrz4VTkQh85JVYbmWmO4JWWU+zSIuKDclgiwM8ynU2WTEZJxYpRLemTgORAzGEZ hAU0EWG9L5qkYe5IvOnmPOQInr894PJpHTdmsclLPduKDhEwhrjPpahn038FlTrr 0mqtT2OvAC1EQ3YEn+0hu5xzzTbntxZUyc/7bjnyLAfH0vxuA7O4T/I1sT6h5BaN VASPEc/yZxURuLTRwCUYFefTGUCGjDiCOcg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvieejvddvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtsfdttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepfeffgfelvdffgedtveelgfdtgefghfdvkefggeetieevjeekteduleevjefh ueegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggvpdhnsggprhgtphhtthhopeehpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopehpghessghofihtrdhivgdprhgtphhtthhopehtvh esfhhuiiiihidrtgiipdhrtghpthhtohepnhhorghhsehlvggruggsohgrthdrtghomhdp rhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehpohhsthhgrhgvshhqlhdrohhrgh dprhgtphhtthhopeiggehmmhhmseihrghnuggvgidqthgvrghmrdhruh X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Mar 2026 14:27:05 -0500 (EST) Date: Thu, 5 Mar 2026 14:27:04 -0500 From: Andres Freund To: Andrey Borodin Cc: pgsql-hackers@postgresql.org, Noah Misch , Tomas Vondra , Peter Geoghegan Subject: Re: gistGetFakeLSN() can return incorrect LSNs Message-ID: References: <65418A7A-9139-486A-9F67-B2F83E148E83@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65418A7A-9139-486A-9F67-B2F83E148E83@yandex-team.ru> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-03-05 23:26:30 +0500, Andrey Borodin wrote: > Interesting bug. Your analysis seems correct to me. > > > On 5 Mar 2026, at 22:10, Andres Freund wrote: > > > > To be safe, this code would need to use a version of GetXLogInsertRecPtr() > > that does use XLogBytePosToEndRecPtr() instead of XLogBytePosToRecPtr(). > > Can't we just take Insert->CurrBytePos without XLogBytePosToEndRecPtr()? > Is there a point in alignment before the page header? No, that'd be a completely bogus LSN, as CurrBytePos does not include any space for page headers, to make the the very contended spinlock'ed section in ReserveXLogInsertLocation() cheaper: /* * The duration the spinlock needs to be held is minimized by minimizing * the calculations that have to be done while holding the lock. The * current tip of reserved WAL is kept in CurrBytePos, as a byte position * that only counts "usable" bytes in WAL, that is, it excludes all WAL * page headers. The mapping between "usable" byte positions and physical * positions (XLogRecPtrs) can be done outside the locked region, and * because the usable byte position doesn't include any headers, reserving * X bytes from WAL is almost as simple as "CurrBytePos += X". */ SpinLockAcquire(&Insert->insertpos_lck); And we rely on the page LSNs to be correct for the content of newly created permanent relations with wal_level=minimal, so you can't just return arbitrary other values. Greetings, Andres Freund