Re: gistGetFakeLSN() can return incorrect LSNs - Mailing list pgsql-hackers

From Noah Misch
Subject Re: gistGetFakeLSN() can return incorrect LSNs
Date
Msg-id 20260305185203.76.noahmisch@microsoft.com
Whole thread Raw
In response to gistGetFakeLSN() can return incorrect LSNs  (Andres Freund <andres@anarazel.de>)
Responses Re: gistGetFakeLSN() can return incorrect LSNs
List pgsql-hackers
On Thu, Mar 05, 2026 at 12:10:11PM -0500, Andres Freund wrote:
> Tomas encountered a crash with the index prefetching patchset. One of the
> patches included therein is a generalization of the gistGetFakeLSN()
> mechanism, which is then used by other indexes as well.  That triggered an
> occasional, hard to locally reproduce, ERROR or PANIC in CI, about
> 
>   ERROR: xlog flush request 0/01BD2018 is not satisfied --- flushed only to 0/01BD2000

> To be safe, this code would need to use a version of GetXLogInsertRecPtr()
> that does use XLogBytePosToEndRecPtr() instead of XLogBytePosToRecPtr().

I agree.  Thanks for diagnosing it.  Feel free to move forward with that
strategy, or let me know if you'd like me to do it.

> However, if I put an XLogFlush() into gistGetFakeLSN() and use
> wal_level=minimal, it's a lot easier.
> 
> 
> It looks like this was introduced in
> 
> commit c6b92041d38
> Author: Noah Misch <noah@leadboat.com>
> Date:   2020-04-04 12:25:34 -0700
> 
>     Skip WAL for new relfilenodes, under wal_level=minimal.

Combining that XLogFlush() with wal_level=minimal (your recipe) does make
predicate-gist.spec fail, both at that commit and today.



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore
Next
From: Marcos Pegoraro
Date:
Subject: on SGML files is used for what ?