Horton

Re: gistGetFakeLSN() can return incorrect LSNs

x4mmm@yandex-team.ru

View thread View on postgr.es
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Noah Misch <noah@leadboat.com>, Tomas Vondra <tv@fuzzy.cz>, Peter Geoghegan <pg@bowt.ie>
Date: 2026-03-06T05:34:26Z
Lists: pgsql-hackers 

> On 6 Mar 2026, at 00:27, Andres Freund <andres@anarazel.de> wrote:
> 
> 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

Thanks! 
Now I see it's documented that "usable bytes position" is not XLogRecPtr at all.
And XLogBytePosToEndRecPtr() is unavoidable for newly created relations in
wal_level=minimal.

Perhaps we can even add an Assert that PageSetLSN() does not stamp LSNs from future.
Sorry for raising off-topic questions, I'll go check this myself.


Best regards, Andrey Borodin.

Commits

  1. Use GetXLogInsertEndRecPtr in gistGetFakeLSN

  2. Skip WAL for new relfilenodes, under wal_level=minimal.