--with-llvm on 32-bit platforms?

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

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.

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.

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

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

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,

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

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,

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.

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

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

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...

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

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.

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

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.

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.

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

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,