Re: Extensions versus pg_upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions versus pg_upgrade
Date: 2011-02-08 17:30:47
Message-ID: 21596.1297186247@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Now what?

> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned?

Um, how about "it doesn't work"?

The reason that data type OIDs have to be preserved, for example, is
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
broken.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2011-02-08 17:33:37 Re: arrays as pl/perl input arguments [PATCH]
Previous Message Euler Taveira de Oliveira 2011-02-08 17:28:42 Re: Allow pg_archivecleanup to ignore extensions