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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
