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

Dmitry Mityugov <d(dot)mityugov(at)postgrespro(dot)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