Tom Lane <tgl@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
