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

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.

Dimitri Fontaine PostgreSQL : Expertise, Formation et Support

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 33 | next ›
Discussion Overview
grouppgsql-hackers @
postedFeb 8, '11 at 4:54p
activeFeb 10, '11 at 4:59p



site design / logo © 2022 Grokbase