On Tue, 27 Jan 2009, Robert Haas wrote:
That implies a fairly robust and configurable system for adding to and rewriting system catalogs, which today we haven't got.
Right, and designing such a system requires a fairly deep analysis of the catalog changes that have historically shown up, to make sure you've got something that will handle them. The first step here that bears some immediate fruit would be to sit down and analyze everything that changed in the catalog from 8.3 to 8.4. Then you can do two things. You can confirm whether the path used by pg_upgrade really can be expected to work. You could also then talk intelligently about what a design for a catalog rewriting system would look like, using "something that could have handled all of these" as your spec. Then it's onto worrying about page format stuff, which you can already get a handle on by looking at 8.2->8.3 under the same lens.
Tom even generated a helpful starting list of things to chase down a few months ago: http://archives.postgresql.org/pgsql-hackers/2008-09/msg00451.php
As someone who has been investigating this particular path, the part that troubles me is that you'd have to pushing a new and completely non-glamorous overhead burden ("create an in-place implementation for your catalog change") on people who don't necessarily care about that particular goal, which would create considerable new friction for patch submission that required a catversion bump. Not the sort of boring work volunteers on a project are traditionally good at, and you can expect any developers who aren't managing databases too large to dump/reload to scream about how it will slow the advance of the project.
-- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
