Re: btree_gist macaddr valgrind woes

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.16 rows=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