Re: pg_upgrade (was: 8.2 features status)

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade (was: 8.2 features status)
Date: 2006-08-07 10:18:26
Message-ID: 20060807101826.GA20081@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote:
> What of having support in the backend for two heap formats in each version.
> That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be
> a flag in pg_class indicating the heap format for that heap. Then you would be
> able to upgrade without rewriting all your tables and the only requirement is
> that sometime prior to the next upgrade you issue a per-table ALTER TABLE that
> involves rewriting the table such as CLUSTER or ALTER COLUMN TYPE USING.

I don't think you need even go that far. The only disk format change
this time I'm aware of is the inet/cidr datatypes. Given most people
don't use those, it would have been fairly easy to manage such a
transistion. If the new types had been identified with a new OID
(probably a good move anyway if the binary send/receive format
changes), all that would've needed to happen would be that pg_upgrase
would:

1. Under old system, munge the system catalog to add code for new inet
type with new OID. Probably needs a shared lib (if you could create
type input/output function with pl/pgsql it would help here).
2. Execute ALTER COLUMN TYPE USING to switch to the new type.
3. Shutdown old server
4. Complete catalog changes
5. Startup new version

There were no wholesale page format changes, so there's not a lot that
needs to be done on that scale. I presume you'd have to do the
transistion at a "safe" point, considering there's no way a backup
server it going to be able to follow this change...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mario Weilguni 2006-08-07 10:29:07 Another Ltree/GiST problem
Previous Message Pavel Stehule 2006-08-07 10:15:48 Re: proposal for PL packages for 8.3.