On 8/8/25 21:14, Tom Lane wrote:
I have just realized that this proposal has a rather nasty defect.
Per the following comment in spgist_private.h:
* If the prefix datum is of a pass-by-value type, it is stored in its
* Datum representation, that is its on-disk representation is of length
* sizeof(Datum). This is a fairly unfortunate choice, because in no other
* place does Postgres use Datum as an on-disk representation; it creates
* an unnecessary incompatibility between 32-bit and 64-bit builds. But the
* compatibility loss is mostly theoretical since MAXIMUM_ALIGNOF typically
* differs between such builds, too. Anyway we're stuck with it now.
This means we cannot change sizeof(Datum), nor reconsider the
pass-by-value classification of any datatype, without potentially
breaking pg_upgrade of some SP-GiST indexes on 32-bit machines.
Now, it looks like this doesn't affect any in-core SP-GiST opclasses.
The only one using a potentially affected type is kd_point_ops which
uses a float8 prefix. That'll have been stored in regular on-disk
format on a 32-bit machine, but if we redefine it as being stored
in 64-bit-Datum format, nothing actually changes. The case that
would be problematic is a prefix type that's 4 bytes or less, and
I don't see any.
A quick search of Debian Code Search doesn't find any extensions
that look like they are using small pass-by-value prefixes either.
So maybe we can get away with just changing this, but it's worrisome.
On the positive side, even if there are any SP-GiST opclasses that
are at risk, the population of installations using them on 32-bit
installs has got to be pretty tiny.
I bet it is indistinguishable from zero...
And the worst-case answer is that you'd have to reindex such indexes
after pg_upgrade.
...and this seems like a reasonable answer if anyone pops up.
BTW, I don't think we can teach pg_upgrade to check for this
hazard, because the SP-GiST APIs are such that the data type
used for prefixes isn't visible at the SQL level.
Do we think that making this change is valuable enough to justify
taking such a risk?
yes +1
--
Joe Conway
PostgreSQL Contributors Team
Amazon Web Services: https://aws.amazon.com
