From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extensions versus pg_upgrade |
Date: | 2011-02-08 20:43:59 |
Message-ID: | m2r5bip88g.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Ports | 2011-02-08 20:53:05 | Re: SSI patch version 14 |
Previous Message | Thom Brown | 2011-02-08 20:35:08 | Re: Named restore points |