Horton

Thread

Commits

  1. jit: Fix type used for Datum values in LLVM IR.

  2. Avoid faulty alignment of Datums in build_sorted_items().

  3. Make type Datum be 8 bytes wide everywhere.

  1. --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-04T21:32:05Z

    It seems that when I add --with-llvm flag to ./configure on any 32-bit 
platform that I have (Debian 12, Debian 13, Arch Linux), many tests 
invoked by `make check` fail, or, sometimes, hang forever. Is this a 
known problem? It's not critical to me, just wanted to know if I should 
abandon --with-llvm forever on such platforms. On 64-bit Linux 
platforms, both x86 and ARM, --with-llvm works fine.

To reproduce, it's enough to:

make distclean
./configure --with-llvm
make -j23 -ks
make check

The last step is never successful to me, and, by the way, this can also 
be reproduced with clang:

make distclean
./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
make -j23 -ks
make check

Thanks in advance for your attention to this problem, or telling me this 
is not a problem at all

  2. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-05T08:11:42Z

    Dmitry Mityugov писал(а) 2025-09-05 00:32:
> It seems that when I add --with-llvm flag to ./configure on any 32-bit 
> platform that I have (Debian 12, Debian 13, Arch Linux), many tests 
> invoked by `make check` fail, or, sometimes, hang forever. Is this a 
> known problem? It's not critical to me, just wanted to know if I should 
> abandon --with-llvm forever on such platforms. On 64-bit Linux 
> platforms, both x86 and ARM, --with-llvm works fine.
> 
> To reproduce, it's enough to:
> 
> make distclean
> ./configure --with-llvm
> make -j23 -ks
> make check
> 
> The last step is never successful to me, and, by the way, this can also 
> be reproduced with clang:
> 
> make distclean
> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
> make -j23 -ks
> make check
> 
> Thanks in advance for your attention to this problem, or telling me 
> this is not a problem at all

One of the reasons I ask this question is that according to 
f5d07085822a1 parameter --with-llvm is now mandatory in some cases, but 
it seems it can't be used.

Regards

  3. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-05T11:32:31Z

    Dmitry Mityugov писал(а) 2025-09-05 11:11:
> Dmitry Mityugov писал(а) 2025-09-05 00:32:
>> It seems that when I add --with-llvm flag to ./configure on any 32-bit 
>> platform that I have (Debian 12, Debian 13, Arch Linux), many tests 
>> invoked by `make check` fail, or, sometimes, hang forever. Is this a 
>> known problem? It's not critical to me, just wanted to know if I 
>> should abandon --with-llvm forever on such platforms. On 64-bit Linux 
>> platforms, both x86 and ARM, --with-llvm works fine.
>> 
>> To reproduce, it's enough to:
>> 
>> make distclean
>> ./configure --with-llvm
>> make -j23 -ks
>> make check
>> 
>> The last step is never successful to me, and, by the way, this can 
>> also be reproduced with clang:
>> 
>> make distclean
>> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
>> make -j23 -ks
>> make check
>> 
>> Thanks in advance for your attention to this problem, or telling me 
>> this is not a problem at all
> 
> One of the reasons I ask this question is that according to 
> f5d07085822a1 parameter --with-llvm is now mandatory in some cases, but 
> it seems it can't be used.

By the way, when I rebuild REL_17_STABLE using the steps above (on 
Debian 13 32-bit is this matters) tests in `make check` pass, so it 
seems that something is broken in master.

  4. Re: --with-llvm on 32-bit platforms?

    Peter Eisentraut <peter@eisentraut.org> — 2025-09-15T06:36:22Z

    On 05.09.25 13:32, Dmitry Mityugov wrote:
> Dmitry Mityugov писал(а) 2025-09-05 11:11:
>> Dmitry Mityugov писал(а) 2025-09-05 00:32:
>>> It seems that when I add --with-llvm flag to ./configure on any 32- 
>>> bit platform that I have (Debian 12, Debian 13, Arch Linux), many 
>>> tests invoked by `make check` fail, or, sometimes, hang forever. Is 
>>> this a known problem? It's not critical to me, just wanted to know if 
>>> I should abandon --with-llvm forever on such platforms. On 64-bit 
>>> Linux platforms, both x86 and ARM, --with-llvm works fine.
>>>
>>> To reproduce, it's enough to:
>>>
>>> make distclean
>>> ./configure --with-llvm
>>> make -j23 -ks
>>> make check
>>>
>>> The last step is never successful to me, and, by the way, this can 
>>> also be reproduced with clang:
>>>
>>> make distclean
>>> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
>>> make -j23 -ks
>>> make check
>>>
>>> Thanks in advance for your attention to this problem, or telling me 
>>> this is not a problem at all
>>
>> One of the reasons I ask this question is that according to 
>> f5d07085822a1 parameter --with-llvm is now mandatory in some cases, 
>> but it seems it can't be used.
> 
> By the way, when I rebuild REL_17_STABLE using the steps above (on 
> Debian 13 32-bit is this matters) tests in `make check` pass, so it 
> seems that something is broken in master.

It seems plausible that this is related to commit 2a600a93c7b "Make type 
Datum be 8 bytes wide everywhere.".  I don't have any more insights than 
that.

  5. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-15T16:23:30Z

    Peter Eisentraut wrote 2025-09-15 09:36:
> On 05.09.25 13:32, Dmitry Mityugov wrote:
>> Dmitry Mityugov писал(а) 2025-09-05 11:11:
>>> Dmitry Mityugov писал(а) 2025-09-05 00:32:
>>>> It seems that when I add --with-llvm flag to ./configure on any 32- 
>>>> bit platform that I have (Debian 12, Debian 13, Arch Linux), many 
>>>> tests invoked by `make check` fail, or, sometimes, hang forever. Is 
>>>> this a known problem? It's not critical to me, just wanted to know 
>>>> if I should abandon --with-llvm forever on such platforms. On 64-bit 
>>>> Linux platforms, both x86 and ARM, --with-llvm works fine.
>>>> 
>>>> To reproduce, it's enough to:
>>>> 
>>>> make distclean
>>>> ./configure --with-llvm
>>>> make -j23 -ks
>>>> make check
>>>> 
>>>> The last step is never successful to me, and, by the way, this can 
>>>> also be reproduced with clang:
>>>> 
>>>> make distclean
>>>> ./configure CC=clang CXX=clang++ --with-llvm CFLAGS=-msse2
>>>> make -j23 -ks
>>>> make check
>>>> 
>>>> Thanks in advance for your attention to this problem, or telling me 
>>>> this is not a problem at all
>>> 
>>> One of the reasons I ask this question is that according to 
>>> f5d07085822a1 parameter --with-llvm is now mandatory in some cases, 
>>> but it seems it can't be used.
>> 
>> By the way, when I rebuild REL_17_STABLE using the steps above (on 
>> Debian 13 32-bit is this matters) tests in `make check` pass, so it 
>> seems that something is broken in master.
> 
> It seems plausible that this is related to commit 2a600a93c7b "Make 
> type Datum be 8 bytes wide everywhere.".  I don't have any more 
> insights than that.

Thanks for the hint. I did git bisect, and it seems that the first ‘bad’ 
commit is this:

commit 2a600a93c7be5b0bf8cacb1af78009db12bc4857
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Aug 13 16:35:06 2025 -0400

    Make type Datum be 8 bytes wide everywhere.
    …

I'll try to look further to understand what particular change in this 
commit is responsible for the problem.

Thank you again

  6. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-15T19:16:21Z

    Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
> Peter Eisentraut wrote 2025-09-15 09:36:
>> It seems plausible that this is related to commit 2a600a93c7b "Make 
>> type Datum be 8 bytes wide everywhere.".  I don't have any more 
>> insights than that.

> Thanks for the hint. I did git bisect, and [ Peter's right ]

Interesting.  You have at no point shown any details about what
these failures look like.  However, I wonder if it could be
something about broken alignment expectations.  The recent
commit 09036dc71 fixed one thing that we'd managed not to notice
in earlier testing, and I can't avoid the suspicion that there's
more.

			regards, tom lane

  7. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-15T20:08:28Z

    Tom Lane писал(а) 2025-09-15 22:16:
> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
>> Peter Eisentraut wrote 2025-09-15 09:36:
>>> It seems plausible that this is related to commit 2a600a93c7b "Make
>>> type Datum be 8 bytes wide everywhere.".  I don't have any more
>>> insights than that.
> 
>> Thanks for the hint. I did git bisect, and [ Peter's right ]
> 
> Interesting.  You have at no point shown any details about what
> these failures look like.  However, I wonder if it could be
> something about broken alignment expectations.  The recent
> commit 09036dc71 fixed one thing that we'd managed not to notice
> in earlier testing, and I can't avoid the suspicion that there's
> more.

I did mention that `make check` fails if I enable --with-llvm flag on 
32-bit Linux platforms, for both GCC and Clang, at the very first 
message in this thread. Sorry if this got lost in quoting and 
formatting.

Thank you for pointing me to the commit, I'll check it.

What's interesting is that when I add the following (quick and dirty) 
assertion to DatumGetPointer on 32-bit Linux platforms,

DatumGetPointer(Datum X)
{
         Assert((X & 0xFFFFFFFF00000000) == 0);
         return (Pointer) (uintptr_t) X;
}

I get a failure in Postgres executable early on startup. If I am 
correct, this means that there are places in the code that assume that 
PointerGetDatum(DatumGetPointer(X)) == X, and this is not true if the 
pointer size is smaller than the Datum size. Hopefully I am not correct 
on this, but this might mean that the problem is broader than just 
enabling --with-llvm.

Thank you for your valuable time,

  8. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-15T20:21:54Z

    Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
> Tom Lane писал(а) 2025-09-15 22:16:
>> Interesting.  You have at no point shown any details about what
>> these failures look like.

> I did mention that `make check` fails if I enable --with-llvm flag on 
> 32-bit Linux platforms, for both GCC and Clang, at the very first 
> message in this thread.

Indeed you said that, but that's about as content-free a problem
report as I've run into.  What are the regression diffs?  (If
they're massive, the first few would still be useful.)  Does it
get hung up entirely?  Are there crashes, and if so can you get
stack traces from them?  You really shouldn't expect people to
spin up an environment like this just to see what happens.

> What's interesting is that when I add the following (quick and dirty) 
> assertion to DatumGetPointer on 32-bit Linux platforms,

> DatumGetPointer(Datum X)
> {
>          Assert((X & 0xFFFFFFFF00000000) == 0);
>          return (Pointer) (uintptr_t) X;
> }

> I get a failure in Postgres executable early on startup.

Interesting, but again, how about a stack trace?

			regards, tom lane

  9. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-15T22:06:32Z

    Tom Lane писал(а) 2025-09-15 23:21:
> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
>> Tom Lane писал(а) 2025-09-15 22:16:
>>> Interesting.  You have at no point shown any details about what
>>> these failures look like.
> 
>> I did mention that `make check` fails if I enable --with-llvm flag on
>> 32-bit Linux platforms, for both GCC and Clang, at the very first
>> message in this thread.
> 
> Indeed you said that, but that's about as content-free a problem
> report as I've run into.  What are the regression diffs?  (If
> they're massive, the first few would still be useful.)  Does it
> get hung up entirely?  Are there crashes, and if so can you get
> stack traces from them?  You really shouldn't expect people to
> spin up an environment like this just to see what happens.
> 
>> What's interesting is that when I add the following (quick and dirty)
>> assertion to DatumGetPointer on 32-bit Linux platforms,
> 
>> DatumGetPointer(Datum X)
>> {
>>          Assert((X & 0xFFFFFFFF00000000) == 0);
>>          return (Pointer) (uintptr_t) X;
>> }
> 
>> I get a failure in Postgres executable early on startup.
> 
> Interesting, but again, how about a stack trace?

Sorry I didn't provide more information earlier. By the way, I pulled 
the latest changes from the master branch and it didn't help. For the 
problem with --with-llvm on 32-bit Debian 13.1 with GCC 14.2, I'm 
attaching the partial console output from `make check`, 5000 first lines 
from src/test/regress/regression.diffs (in particular, it contains a 
bunch of these: "error: connection to server on socket 
"/tmp/pg_regress-y0DQT8/.s.PGSQL.58928" failed"), and 
src/test/regress/log/postmaster.log. Please let me know if I should send 
more traces of the problem.

The number of tests that fail is random and is between 25-160, out of 
229 total. Sometimes the tests hang entirely and I have to press Ctrl-C 
to interrupt them.

When I enable the aforementioned assert and start `make check`, I 
immediately get in tmp_install/log/initdb-template.log:

Running in no-clean mode.  Mistakes will not be cleaned up.
The files belonging to this database system will be owned by user "dd".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are enabled.

creating directory 
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/initdb-template 
... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Europe/Moscow
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... TRAP: failed Assert("(X & 
0xFFFFFFFF00000000) == 0"), File: "../../../../src/include/postgres.h", 
Line: 324, PID: 427452
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExceptionalCondition+0x6b) 
[0x56c990cb]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(toast_tuple_init+0x2f1) 
[0x567c19e1]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(heap_toast_insert_or_update+0xe0) 
[0x56776b60]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x1a77bc) 
[0x567617bc]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(heap_insert+0x69) 
[0x56765509]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(simple_heap_insert+0x2d) 
[0x5676660d]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(CatalogTupleInsertWithInfo+0x34) 
[0x5681a734]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x2c7fed) 
[0x56881fed]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x2caca9) 
[0x56884ca9]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(analyze_rel+0x198) 
[0x568864e8]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(vacuum+0x4cc) 
[0x569066ec]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExecVacuum+0x1db) 
[0x56906e8b]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(standard_ProcessUtility+0x7ed) 
[0x56b2825d]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x56c02d) 
[0x56b2602d]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x56c198) 
[0x56b26198]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PortalRun+0x18b) 
[0x56b266fb]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(+0x5677a8) 
[0x56b217a8]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PostgresMain+0x1a17) 
[0x56b23667]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(PostgresSingleUserMain+0x10b) 
[0x56b24c2b]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(main+0x4c4) 
[0x5670a504]
/lib/i386-linux-gnu/libc.so.6(+0x24cc3) [0xf75bbcc3]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0x88) [0xf75bbd88]
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(_start+0x27) 
[0x5670a5a7]
Aborted (core dumped)
child process exited with exit code 134
initdb: data directory 
"/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/initdb-template" 
not removed at user's request

It's probably possible to reproduce the problem on a 64-bit Linux (that 
is, define Datum as uint128 to trigger the assert above) but I'm not 
sure if this will be the only change required.

Regards,

  10. Re: --with-llvm on 32-bit platforms?

    Thomas Munro <thomas.munro@gmail.com> — 2025-09-15T23:09:02Z

    On Tue, Sep 16, 2025 at 8:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
> > What's interesting is that when I add the following (quick and dirty)
> > assertion to DatumGetPointer on 32-bit Linux platforms,
>
> > DatumGetPointer(Datum X)
> > {
> >          Assert((X & 0xFFFFFFFF00000000) == 0);
> >          return (Pointer) (uintptr_t) X;
> > }
>
> > I get a failure in Postgres executable early on startup.
>
> Interesting, but again, how about a stack trace?

Hmm.  We use TypeSizeT in generated IR for Datum, which is obviously
incorrect in this configuration.

  11. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-16T00:04:55Z

    Thomas Munro <thomas.munro@gmail.com> writes:
>> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
>>> I get a failure in Postgres executable early on startup.

>> Interesting, but again, how about a stack trace?

> Hmm.  We use TypeSizeT in generated IR for Datum, which is obviously
> incorrect in this configuration.

Oh!  Yeah, that is surely broken now.  But it'd only explain problems
once you reach JIT-ed code, which I'd not expect to happen "early on
startup".  So maybe there's another problem?

			regards, tom lane

  12. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-16T00:31:59Z

    Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
> Tom Lane писал(а) 2025-09-15 23:21:
>> Interesting, but again, how about a stack trace?


> performing post-bootstrap initialization ... TRAP: failed Assert("(X & 
> 0xFFFFFFFF00000000) == 0"), File: "../../../../src/include/postgres.h", 
> Line: 324, PID: 427452

> /home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExceptionalCondition+0x6b) 
> [0x56c990cb]
> /home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(toast_tuple_init+0x2f1) 
> [0x567c19e1]

Ah-hah.  What's going on there is that toast_tuple_init does

            old_value =
                (struct varlena *) DatumGetPointer(ttc->ttc_oldvalues[i]);
            new_value =
                (struct varlena *) DatumGetPointer(ttc->ttc_values[i]);

before checking if the values are NULL.  Now, this is at least
theoretically okay because it doesn't try to dereference either
pointer until it's checked the isnull flags.  But the Datum it's
reading might well be garbage, thus triggering your assertion.

I don't see a really nice way to avoid this.  We could perhaps
do something like

            old_value =
                (struct varlena *)
                    (ttc->ttc_oldisnull[i] ? NULL : DatumGetPointer(ttc->ttc_oldvalues[i]));

but adding extra cycles here isn't very appetizing.

If you want to pursue it further you could temporarily patch
toast_tuple_init and then see if you get any further, but I'm
not sure you'll learn anything interesting.  I think Munro
has put his finger on the problem.

			regards, tom lane

  13. Re: --with-llvm on 32-bit platforms?

    Thomas Munro <thomas.munro@gmail.com> — 2025-09-16T00:51:21Z

    On Tue, Sep 16, 2025 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Hmm.  We use TypeSizeT in generated IR for Datum, which is obviously
> > incorrect in this configuration.
>
> Oh!  Yeah, that is surely broken now.  But it'd only explain problems
> once you reach JIT-ed code, which I'd not expect to happen "early on
> startup".  So maybe there's another problem?

Should be easy enough to fix, I just have to remember how to set up a
32 bit environment...  on it...

  14. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-16T07:21:30Z

    Tom Lane писал(а) 2025-09-16 03:31:
> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
>> Tom Lane писал(а) 2025-09-15 23:21:
>>> Interesting, but again, how about a stack trace?
> 
> 
>> performing post-bootstrap initialization ... TRAP: failed Assert("(X &
>> 0xFFFFFFFF00000000) == 0"), File: 
>> "../../../../src/include/postgres.h",
>> Line: 324, PID: 427452
> 
>> /home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExceptionalCondition+0x6b)
>> [0x56c990cb]
>> /home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(toast_tuple_init+0x2f1)
>> [0x567c19e1]
> 
> Ah-hah.  What's going on there is that toast_tuple_init does
> 
>             old_value =
>                 (struct varlena *) 
> DatumGetPointer(ttc->ttc_oldvalues[i]);
>             new_value =
>                 (struct varlena *) DatumGetPointer(ttc->ttc_values[i]);
> 
> before checking if the values are NULL.  Now, this is at least
> theoretically okay because it doesn't try to dereference either
> pointer until it's checked the isnull flags.  But the Datum it's
> reading might well be garbage, thus triggering your assertion.
> 
> I don't see a really nice way to avoid this.  We could perhaps
> do something like
> 
>             old_value =
>                 (struct varlena *)
>                     (ttc->ttc_oldisnull[i] ? NULL : 
> DatumGetPointer(ttc->ttc_oldvalues[i]));
> 
> but adding extra cycles here isn't very appetizing.

Thank you for the explanation.

> If you want to pursue it further you could temporarily patch
> toast_tuple_init and then see if you get any further, but I'm
> not sure you'll learn anything interesting.  I think Munro
> has put his finger on the problem.

This, unrelated to --with-llvm, task, can be pursued on a 64-bit Linux, 
provided the system has the multilibs installed and -m32 was added to 
the list of compiler options, like in

make distclean -s && ./configure CFLAGS="-Og -m32" --enable-cassert && 
make -sj23 && make check

I created a secondary DatumGetPointer() function, with a bit different 
name and without the assert, reproduced the failure using the command 
line above, replaced all calls to DatumGetPointer() function in 
toast_tuple_init() with the version without assert... And have found no 
more problems so far. At least `make check` passes clearly.

Thank you again

  15. Re: --with-llvm on 32-bit platforms?

    Thomas Munro <thomas.munro@gmail.com> — 2025-09-16T13:34:45Z

    On Tue, Sep 16, 2025 at 12:51 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Sep 16, 2025 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@gmail.com> writes:
> > > Hmm.  We use TypeSizeT in generated IR for Datum, which is obviously
> > > incorrect in this configuration.
> >
> > Oh!  Yeah, that is surely broken now.

This patch seems to work OK here.  The deform code is a little tricky
as you have to think carefully about which places need TypeDatum and
which need TypeSizeT in llvmjit_deform.c, since the v_offp variable
really is size_t.  Tested on Debian 13 with i386 packages installed.

More changes would be needed if Datum is changed into a struct.

  16. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-16T13:45:10Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> On Tue, Sep 16, 2025 at 12:51 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Tue, Sep 16, 2025 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Oh!  Yeah, that is surely broken now.

> This patch seems to work OK here.  The deform code is a little tricky
> as you have to think carefully about which places need TypeDatum and
> which need TypeSizeT in llvmjit_deform.c, since the v_offp variable
> really is size_t.  Tested on Debian 13 with i386 packages installed.

Thanks for doing that.  It looks generally plausible to my eye,
but I'm hardly qualified to do a detailed review.

> More changes would be needed if Datum is changed into a struct.

I can only imagine us doing that as a compile option to help
catch errors.  Our ambition need not reach to making the compile
option play with --with-llvm, perhaps.

			regards, tom lane

  17. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-16T15:47:18Z

    Tom Lane wrote 2025-09-16 16:45:
> Thomas Munro <thomas.munro@gmail.com> writes:
>> On Tue, Sep 16, 2025 at 12:51 PM Thomas Munro <thomas.munro@gmail.com> 
>> wrote:
>>> On Tue, Sep 16, 2025 at 12:05 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Oh!  Yeah, that is surely broken now.
> 
>> This patch seems to work OK here.  The deform code is a little tricky
>> as you have to think carefully about which places need TypeDatum and
>> which need TypeSizeT in llvmjit_deform.c, since the v_offp variable
>> really is size_t.  Tested on Debian 13 with i386 packages installed.
> 
> Thanks for doing that.  It looks generally plausible to my eye,
> but I'm hardly qualified to do a detailed review.
> 
>> More changes would be needed if Datum is changed into a struct.
> 
> I can only imagine us doing that as a compile option to help
> catch errors.  Our ambition need not reach to making the compile
> option play with --with-llvm, perhaps.

I tried the patch and it works well, thanks a lot to everyone involved 
in fixing this.

  18. Re: --with-llvm on 32-bit platforms?

    Thomas Munro <thomas.munro@gmail.com> — 2025-09-17T03:30:44Z

    On Wed, Sep 17, 2025 at 3:47 AM Dmitry Mityugov
<d.mityugov@postgrespro.ru> wrote:
> I tried the patch and it works well, thanks a lot to everyone involved
> in fixing this.

Thanks for the report and confirmation!  I also pinged Andres just in
case he had any objections to the approach, given that he wrote this
stuff.  Nope, so pushed.

As a side note, apt.llvm.org is apparently no longer publishing 32 bit
packages, and Debian's own i386 packages for LLVM bits and pieces seem
to have some inconvenient conflicts with their amd64 twins, and
indirectly lots of other stuff including my window manager (!).  Or
perhaps it was always like that, and I'm recalling apt.llvm.org's old
32 bit packages.  All perfectly manageable in a dedicated
VM/container/chroot, but I wonder how long multiarch support will
continue.

  19. Re: --with-llvm on 32-bit platforms?

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-09-17T03:47:36Z

    Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Sep 17, 2025 at 3:47 AM Dmitry Mityugov
> <d.mityugov@postgrespro.ru> wrote:
>> I tried the patch and it works well, thanks a lot to everyone involved
>> in fixing this.

> Thanks for the report and confirmation!  I also pinged Andres just in
> case he had any objections to the approach, given that he wrote this
> stuff.  Nope, so pushed.

Thanks for taking care of that!

> As a side note, apt.llvm.org is apparently no longer publishing 32 bit
> packages, and Debian's own i386 packages for LLVM bits and pieces seem
> to have some inconvenient conflicts with their amd64 twins, and
> indirectly lots of other stuff including my window manager (!).  Or
> perhaps it was always like that, and I'm recalling apt.llvm.org's old
> 32 bit packages.  All perfectly manageable in a dedicated
> VM/container/chroot, but I wonder how long multiarch support will
> continue.

I think that for mainstream Linux distros, the handwriting on the
wall is getting clearer and clearer.  Fedora stopped supporting
any 32-bit architectures some time ago, and Debian has dropped
the first shoe (i386) too.  (They might still build some 32-bit
libraries, but I don't see the point of worrying about that case.
If you're on a fundamentally 64-bit system, surely Postgres is not
one of the applications you want to cram into 32-bit.)

The various BSDen and maybe some niche Linux distros are probably
the only platforms we should be worrying about for 32-bit.

Despite having been the one who started this particular round of
changes, I do foresee that PG will drop 32-bit support altogether
in not so many years.  I'm willing to keep kicking that can
down the road for a little while more, though.

			regards, tom lane

  20. Re: --with-llvm on 32-bit platforms?

    Dmitry Mityugov <d.mityugov@postgrespro.ru> — 2025-09-17T20:18:22Z

    Thomas Munro wrote 2025-09-17 06:30:
> On Wed, Sep 17, 2025 at 3:47 AM Dmitry Mityugov
> <d.mityugov@postgrespro.ru> wrote:
>> I tried the patch and it works well, thanks a lot to everyone involved
>> in fixing this.
> 
> Thanks for the report and confirmation!  I also pinged Andres just in
> case he had any objections to the approach, given that he wrote this
> stuff.  Nope, so pushed.

Just wanted to add that this patch also fixes the problem when 
--with-llvm is enabled on 32-bit ARMs; tests from `make check` pass 
clearly when Postgres is build with this option enabled with both GCC 
and Clang on 32-bit Debian 13.1 for armhf architecture.

Regards,