Tom Lane <t...@sss.pgh.pa.us> writes: > that they might be out on disk. Suppose that you have the cube > extension installed and there are some user tables containing columns of > type cube[]. Those arrays are going to have type cube's OID embedded in > them. If cube has a different OID after pg_upgrade then the arrays are > broken.
Forgot about the internals of arrays. Sure, that's a problem here. > Even letting an extension script run and create data types that weren't > there at all before is problematic, since those types could easily claim > OIDs that need to be reserved for pre-existing types that appear later > in the dump script. > > Similar issues arise for the other cases where pg_upgrade is forcing OID > assignments; it's not doing that just for fun. There's provision to forcing the OID of an extension at CREATE EXTENSION time in the UPGRADE patch, but it does not handle the extension objects. I though system OIDs and user OIDs can't clash because of a 16384 counter magic assignment at initdb, so I'm having a hard time getting to understand exactly the problem case. Will spend time on it tomorrow, if that still helps. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers