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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
