Horton

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

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Yuri Zamyatin <yuri@yrz.am>
Cc: Jeff Davis <pgsql@j-davis.com>, Amit Langote <amitlangote09@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-10-17T21:25:25Z
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 →

  1. Fix reset of incorrect hash iterator in GROUPING SETS queries

  2. Fix EPQ crash from missing partition directory in EState

Attachments

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