Re: BUG #19082: Failing assert in index scan

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>

To: Matthijs van der Vleuten <postgresql@zr40.nl>

Cc: pgsql-bugs@lists.postgresql.org

Date: 2025-10-10T18:22:16Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Remove overzealous _bt_killitems assertion.
- 843e50208a31 19 (unreleased) landed
- 61de81a496dc 18.1 landed
- ae15cebc2035 17.7 landed
- c160fd46910e 16.11 landed
- ca0c9390865d 15.15 landed
- 314004021e54 14.20 landed
- af302ff6b84a 13.23 landed
Make _bt_killitems drop pins it acquired itself.
- c7f25feb3862 16.10 cited

On Fri, Oct 10, 2025 at 2:10 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Are you using wal_level = minimal, then?

Matthijs confirms (off list) that wal_level = minimal has been used.
So it looks like the assertion itself is wrong; it isn't accounting
for the possibility that the LSN from currPos is InvalidXLogRecPtr/0
due solely to the index build never needing to be logged.

I actually copied this _bt_killitems assertion from the similar code
path in GiST (the one at the top of gistkillitems). That won't cause
an assertion failure following an index build with wal_level = minimal
because the index build will still set the page LSN to GistBuildLSN.
That's not the case in nbtree -- nbtree doesn't use fake LSNs with
unlogged relations (although I think that it should, specifically to
remove special case handling of unlogged relations within
_bt_killitems).

Anyway, the fix is simple: remove the overzealous assertion. I'll take
care of that shortly.

-- 
Peter Geoghegan