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@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
