Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 10 Oct 2025 13:14:19 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: postgresql@zr40.nl, pgsql-bugs@lists.postgresql.org
Cc: Peter Geoghegan <pg@bowt.ie>
Subject: Re: BUG #19082: Failing assert in index scan
Message-ID: <202510101109.xc4mj5lzidv7@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <19082-628e62160dbbc1c1@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/202510101109.xc4mj5lzidv7%40alvherre.pgsql>
Precedence: bulk

On 2025-Oct-10, PG Bug reporting form wrote:

> Last week, I've noticed a crash due to a failed assertion that was
> consistently being triggered by an application every 10 seconds. Here's the
> log:
> 
> ---
> TRAP: failed Assert("!XLogRecPtrIsInvalid(so->currPos.lsn)"), File:
> "./build/../src/backend/access/nbtree/nbtutils.c", Line: 1782, PID: 394782
> postgres: mastodon mastodon_production [local]
> SELECT(ExceptionalCondition+0x75) [0x55f9c3027ea5]

AFAICS this assertion is new as of commit c7f25feb3862.  Peter?

I find it rather odd that you're running a production instance compiled
with assertions enabled, though.  They have a considerable impact on
performance, and should be used for development or testing only, not
production.  I would recommend to recompile with assertions disabled.
Also, it might well be that the assertion is buggy, and that nothing
would go wrong if that assertion is removed and just let the `if` test
below handle the case.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/