On Sat, May 17, 2014 at 11:46:39PM +0300, Heikki Linnakangas wrote:
> >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?
>
> I think it would be best to just not allow pg_upgrade if there are
> any indexes using the ill-defined types. The upgrade script could
> then simply drop the types and re-create them. The DBA would need to
> drop the affected indexes before upgrade and re-create them
> afterwards, but I think that would be acceptable. I doubt there are
> many people using btree_gist on int8 or float8 columns.
>
> Another way to attack this would be to change the code to memcpy()
> the values before accessing them. That would be ugly, but it would
> be back-patchable. In HEAD, I'd rather bite the bullet and get the
> catalogs fixed, though.
What did we decide about this issue/fix and pg_upgrade?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +