Re: pg_upgrade libraries check - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_upgrade libraries check
Date
Msg-id CA+TgmobjHdoannxc6VwZdDQ-oHpxoBPXgPk4D7jz5M51nKnNzw@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade libraries check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade libraries check
List pgsql-hackers
On Sun, May 27, 2012 at 11:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't recall exactly what problems drove us to make pg_upgrade do
> what it does with extensions, but we need a different fix for them.

Well, you need pg_upgrade to preserve the OIDs of objects that are
part of extensions just as you do for any other objects.  If pg_dump
--binary-upgrade just emits "CREATE EXTENSION snarfle", for some
extension snarfle that provides an eponymous type, then the new
cluster is going to end up with a type with a different OID than than
whatever existed in the old cluster, and that's going to break all
sorts of things - e.g. arrays already on disk that contain the old
type OID.

I think that it would be an extremely fine thing if we could fix the
world so that we not preserve OIDs across a pg_upgrade; that would be
all kinds of wonderful.  However, I think that's likely to be quite a
difficult project.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Per-Database Roles
Next
From: Peter Eisentraut
Date:
Subject: pg_basebackup --xlog compatibility break