| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: gistGetFakeLSN() can return incorrect LSNs |
| Date: | 2026-03-06 05:34:26 |
| Message-ID: | 080D7D73-EEC7-4C5B-9E91-5CF32FE037DF@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 6 Mar 2026, at 00:27, Andres Freund <andres(at)anarazel(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | yangyz | 2026-03-06 05:48:42 | Re: Add pg_stat_recovery system view |
| Previous Message | Nitin Jadhav | 2026-03-06 05:32:41 | Re: Change checkpoint‑record‑missing PANIC to FATAL |