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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Дата
Msg-id CAApHDvrt0hDOUsB3k9tPiT8rTMn0O=8HK3EHRRJ57DC+5bEecg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade  (Yuri Zamyatin <yuri@yrz.am>)
Ответы Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Список 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

Вложения

В списке pgsql-bugs по дате отправления: