Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Date
Msg-id CAApHDvrt0hDOUsB3k9tPiT8rTMn0O=8HK3EHRRJ57DC+5bEecg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade  (Yuri Zamyatin <yuri@yrz.am>)
Responses Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
List pgsql-bugs
Thanks for doing all the extra debugging.

On Sat, 18 Oct 2025 at 09:09, Yuri Zamyatin <yuri@yrz.am> wrote:
> > $84 = {size = 16, members = 4, sizemask = 15, grow_threshold = 14, data = 0x55601c182b98, ctx = 0x55601c1819b0,
private_data= 0x55601c182ac8}
 
> > (gdb) print *entry
> > $86 = {firstTuple = 0x1b, status = 1, hash = 21856}
>
> Does it look suspicious?
> perhash->hashiter->end=43, hashtable->hashtab->size=16, 43-16=0x1b

If that's the iterator for that hash table, then that's a big problem.
hashiter->end should never be >= hashtab->size. If that happens we'll
index over the end of the bucket array, and that might explain why the
firstTuple field is set to an invalid pointer.

Are you able to build with Asserts and try and get an Assert failure
with the attached patch?

If this fails then maybe we're using the wrong iterator somewhere in
nodeAgg.c. I can't see any other way for the iterator's 'end' field to
be bigger than the table's size.

David

Attachment

pgsql-bugs by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases
Next
From: David Rowley
Date:
Subject: Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade