Re: BUG #19082: Failing assert in index scan

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Matthijs van der Vleuten <postgresql(at)zr40(dot)nl>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19082: Failing assert in index scan
Date: 2025-10-10 18:22:16
Message-ID: CAH2-Wzk_kSUi4CWuNMxSDRHcBDaj6S_s3pJn-hDvBts+JN5+SQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 10, 2025 at 2:10 PM Peter Geoghegan <pg(at)bowt(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Nathan Bossart 2025-10-10 20:09:25 Re: Date/Time parsing of ISO 8601 timestamps with commas
Previous Message Peter Geoghegan 2025-10-10 18:10:51 Re: BUG #19082: Failing assert in index scan