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:

Reply via email to