From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Extensions versus pg_upgrade |
Date: | 2011-02-10 02:03:55 |
Message-ID: | 201102100203.p1A23tF11906@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
> > back up to a must-have-for-9.1, since pg_upgrade would then leave you
> > with a non-upgraded extension.
> >
> > Now what?
>
> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned? After all those
> can be considered as part of the schema, not part of the data, and the
> system catalogs are upgraded by the tool.
>
> It would then only break user objects that depend on the extension's
> objects OIDs, but that would be the same if they instead recorded the
> OID of catalog entries, right?
>
> So a valid answer for me would be that when you pg_upgrade, the
> extensions are installed again from their scripts. If you want to go
> further than that, you can insist on having the same version of the
> extension on both sides, but that would defeat the purpose of the tool
> somehow. After all you asked for an upgrade?
The C comment in pg_upgrade.c explains the problem:
* We control all assignments of pg_type.oid because these oids are stored
* in user composite type values.
(Wow, I am glad I recorded all these details.)
The problem is that pg_dump --binary-upgrade knows to call
binary_upgrade.set_next_pg_type_oid() before CREATE TYPE (you can test
it yourself to see), and I am afraid we will need to do something like
that in the extension code, perhaps by supporting a --binary-upgrade
flag like we do for pg_dump. That seems to be the cleanest approach.
A worse approach would be to somehow pass oids to pg_upgrade and have it
renumber things but that seems hopelessly error-prone.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-02-10 02:09:24 | Re: Sync Rep for 2011CF1 |
Previous Message | Itagaki Takahiro | 2011-02-10 02:00:27 | Re: another mvcc.sgml typo |