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
