agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Masao Fujii <masao.fujii@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Revert online data checksum transitions
Date: Wed, 16 Sep 2026 13:14:06 -0400
Message-ID: <506529.1789578846@sss.pgh.pa.us> (raw)
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>
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
view thread (19+ messages) latest in thread
Message-ID: <506529.1789578846@sss.pgh.pa.us>
Permalink: ../506529.1789578846@sss.pgh.pa.us/
Also on: postgresql.org/message-id/506529.1789578846@sss.pgh.pa.us
reply
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-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, daniel@yesql.se, masao.fujii@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Revert online data checksum transitions
In-Reply-To: <506529.1789578846@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox