Dimitri Fontaine wrote:
Tom Lane <tgl@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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 28 of 33 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 8, '11 at 4:54p
activeFeb 10, '11 at 4:59p
posts33
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase