Message-ID: <514ea5ef5120c380856226ec98951a55ef6f40c3.camel@j-davis.com>
Subject: Re: BUG #19078: Segfaults in tts_minimal_store_tuple() following
 pg_upgrade
From: Jeff Davis <pgsql@j-davis.com>
To: David Rowley <dgrowleyml@gmail.com>, Yuri Zamyatin <yuri@yrz.am>, Amit
 Langote <amitlangote09@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: Thu, 16 Oct 2025 12:40:49 -0700
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/514ea5ef5120c380856226ec98951a55ef6f40c3.camel%40j-davis.com>
Precedence: bulk

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=3D=3D0x1b, 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.