I wrote:
> BTW, the *real* problem with all this stuff is that the gbtreekeyNN types
> are declared as having int alignment, even though some of the opclasses
> store double-aligned types in them. I imagine it's possible to provoke
> bus errors on machines that are picky about alignment. The first column
> of an index is safe enough because index tuples will be double-aligned
> anyway, but it seems like there's a hazard for lower-order columns.
And indeed there is:
regression=# create extension btree_gist ;
CREATE EXTENSION
regression=# create table tt (f1 int2, f2 float8);
CREATE TABLE
regression=# create index on tt using gist(f1,f2);
CREATE INDEX
regression=# insert into tt values(1,2);
INSERT 0 1
regression=# insert into tt values(2,4);
INSERT 0 1
regression=# set enable_seqscan TO 0;
SET
regression=# explain select * from tt where f1=2::int2 and f2=4; QUERY PLAN
------------------------------------------------------------------------Index Scan using tt_f1_f2_idx on tt
(cost=0.14..8.16rows=1 width=10) Index Cond: ((f1 = 2::smallint) AND (f2 = 4::double precision))Planning time: 1.043
ms
(3 rows)
regression=# select * from tt where f1=2::int2 and f2=4;
<< bus error >>
> This is something we cannot fix compatibly :-(
AFAICS, what we have to do is mark the wider gbtreekeyNN types as
requiring double alignment. This will break pg_upgrade'ing any index in
which they're used as non-first columns, unless perhaps all the preceding
columns have at least double size/alignment. I guess pg_upgrade can
check for that, but it'll be kind of a pain.
Another issue is what the heck btree_gist's extension upgrade script ought
to do about this. It can't just go and modify the type declarations.
Actually, on further thought, this isn't an issue for pg_upgrade at all,
just for the extension upgrade script. Maybe we just have to make it
poke through the catalogs looking for at-risk indexes, and refuse to
complete the extension upgrade if there are any?
regards, tom lane