Dimitri Fontaine wrote: > Tom Lane <t...@sss.pgh.pa.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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
