Daniel Gustafsson <daniel@yesql.se> writes:
>> On 16 Sep 2026, at 17:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I can poke into it on longfin's host if that would help.
> That would be great, thanks.
What seems to be happening is
(1) pg_control_checkpoint()'s local values[] and nulls[] arrays
are now of length 19.
(2) But the tupdesc that get_call_result_type() builds from the
pg_proc entry still has 20 columns.
(3) Therefore, heap_form_tuple sees a wrong value for the 19th column
(which does no great damage, since it's still a pass-by-value type)
and then fetches complete garbage from values[19] and nulls[19].
Depending on the stack layout and the phase of the moon, nulls[19]
might read as zero or it might not. Either case is fine so long as
heap_compute_data_size and heap_fill_tuple/fill_val interpret it the
same way. However, what I'm seeing as I trace through the crash on
longfin is that nulls[19] has a value that's not either 0 or 1 (not
too surprising), and somehow heap_compute_data_size is interpreting
that as "true" while fill_val is reading it as "false". According
to my understanding of the C standard, fill_val is in the wrong here.
I looked at the generated assembly code and could not spot exactly
what the problem is; it seems to be testing the byte value with
.loc 0 301 7 is_stmt 1 ## heaptuple.c:301:7
testb %al, %al
je LBB3_6
which certainly looks like it ought to treat all nonzero values alike.
Anyway this seems to be a code generation quirk of certain versions of
clang. It's probably not worth chasing further.
regards, tom lane
