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.
signature.asc
Description: Digital signature
