Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Yuri Zamyatin <yuri(at)yrz(dot)am>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Date: 2025-10-17 21:25:25
Message-ID: CAApHDvrt0hDOUsB3k9tPiT8rTMn0O=8HK3EHRRJ57DC+5bEecg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks for doing all the extra debugging.

On Sat, 18 Oct 2025 at 09:09, Yuri Zamyatin <yuri(at)yrz(dot)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 Content-Type Size
add_asserts_to_simplehash_iterator_code.patch application/octet-stream 510 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Rowley 2025-10-17 21:45:06 Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Previous Message Álvaro Herrera 2025-10-17 20:50:30 Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases