From: Jeff Davis <pgsql@j-davis.com>
To: David Rowley <dgrowleyml@gmail.com>
To: Yuri Zamyatin <yuri@yrz.am>
To: Amit Langote <amitlangote09@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
Date: Thu, 16 Oct 2025 12:40:49 -0700
Message-ID: <514ea5ef5120c380856226ec98951a55ef6f40c3.camel@j-davis.com> (raw)
In-Reply-To: <CAApHDvoEJ6z89TQxtC_Zi6xtGyTNzcrtJs=6MMO_-vybWQE6gA@mail.gmail.com>
References: <19078-dfd62f840a2c0766@postgresql.org>
<614d31c9bef9152f90a60bb968f7e855e6164e9c.camel@j-davis.com>
<3b5kvjfavnciubmv7zefmzknlraehlfxufs724nqof7f7x5doh@4qiaendsrrmk>
<CAApHDvriuYHvGcuci+h6kMc306DgHkfTbro53AU=3UokpSOSOw@mail.gmail.com>
<4snsumdqugwza34lnc3vivg63i7s6imql5qopxcmg4xul4w3ft@o3gn2tanz3a3>
<CAApHDvqS_SwUEKbgfNezy42QHsd8BJEgBNLFZ-OAtJogXBfT1Q@mail.gmail.com>
<ly6rss443iajiv5cfypzu6fgrmxdbwzdtuujkddr4eis7s2gcq@gcdytigety6e>
<CAApHDvrFED25iQckJ6ZTdG+nnfnHtaxZ31J_U-ptCKHdY_JdnA@mail.gmail.com>
<CAApHDvoEJ6z89TQxtC_Zi6xtGyTNzcrtJs=6MMO_-vybWQE6gA@mail.gmail.com>
On Thu, 2025-10-16 at 11:51 +1300, David Rowley wrote:
> I forgot to mention, this isn't the same thing as the
> tts_minimal_store_tuple() issue you first reported, so if there is a
> problem there, this one has nothing to do with it.
I investigated, but came up empty so far. Any additional info on the
hashagg crash would be appreciated.
I appended my raw notes below in case someone notices a mistake.
Regards,
Jeff Davis
Raw notes:
* Somehow entry->firstTuple==0x1b, which is obviously wrong.
* The entry structure lives in the bucket array, allocated in the
metacxt using MCXT_ALLOC_ZERO, so there's no uninitialized memory
floating around in the bucket array.
* The metacxt (aggstate->hash_metacxt) is an AllocSet, and it's never
reset. It contains the bucket array as well as some ExprStates and an
ExprContext for evaluating hash functions.
* Hash entries are never deleted, but between batches the entire hash
table is reset (which memsets the entire bucket array to zero).
* The entry->firstTuple is assigned only in one place, from
ExecCopySlotMinimalTupleExtra(). The 'extra' argument is a multiple of
16.
* ExecCopySlotMinimalTupleExtra() does some interesting pointer math,
but I didn't find any path that could plausibly return something like
0x1b. The memory is allocated with palloc/palloc0, which cannot return
zero, and 0x1b is not a multiple of 16 so seems unrelated to the extra
argument.
* JIT does not seem to be involved, because it's going through
ExecInterpExpr().
* When the hash table grows, it invalidates previously-returned entry
pointers. But, given the site of the crash, I don't see that as a
problem in this case.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: pgsql@j-davis.com, dgrowleyml@gmail.com, yuri@yrz.am, amitlangote09@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following pg_upgrade
In-Reply-To: <514ea5ef5120c380856226ec98951a55ef6f40c3.camel@j-davis.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox