From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: Masao Fujii <masao.fujii@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Revert online data checksum transitions
In-reply-to: <217BB68C-9A50-4FA0-B096-818FAC61D85E@yesql.se>
References: 
 <CAHGQGwH-wHTq4xd2dedEj0niDHkezcCT_OLmMpGp9NEHW4Dvkw@mail.gmail.com>
 <1EEAFCFB-15DB-4EC1-BD49-964C799A01B2@yesql.se>
 <501934.1789573768@sss.pgh.pa.us>
 <217BB68C-9A50-4FA0-B096-818FAC61D85E@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Wed, 16 Sep 2026 17:50:59 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <506528.1789578846.1@sss.pgh.pa.us>
Date: Wed, 16 Sep 2026 13:14:06 -0400
Message-ID: <506529.1789578846@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/506529.1789578846%40sss.pgh.pa.us>
Precedence: bulk

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