Re: State of Beta 2

On Fri, 19 Sep 2003 17:38:13 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>> A working pg_upgrade is *not* the first thing we need.
>
>Yes it is.

At the risk of being called a stubborn hairsplitter, I continue to say
that pg_upgrade is not the *first* thing we need. Maybe the second
...

> As you say later,
>
>> ... But once the infrastructure is in place, things
>> should get easier.

Yes, at some point in time we need an infrastructure/upgrade
process/tool/pg_upgrade, whatever we call it. What I tried to say is
that *first* developers must change their point of view and give
backwards compatibility a higher priority. As long as I don't write
page conversion functions because you changed the system catalogs and
you see no need for pg_upgrade because I broke the page format,
seamless upgrade cannot become a reality.

>Until we have a working pg_upgrade, every little catalog change will
>break backwards compatibility. And I do not feel that the appropriate
>way to handle catalog changes is to insist on one-off solutions for each
>one.

I tend to believe that every code change or new feature that gets
implemented is unique by its nature, and if it involves catalog
changes it requires a unique upgrade script/tool. How should a
generic tool guess the contents of a new catalog relation?

Rod's adddepend is a good example. It is a one-off upgrade solution,
which is perfectly adequate because Rod's dependency patch was a
singular work, too. Somebody had to sit down and code some logic into
a script.

> Any quick look at the CVS logs will show that minor and major
>catalog revisions occur *far* more frequently than changes that would
>affect on-disk representation of user data.

Some catalog changes can be done by scripts executed by a standalone
backend, others might require more invasive surgery. Do you have any
feeling which kind is the majority?

I've tried to produce a prototype for seamless upgrade with the patch
announced in
http://archives.postgresql.org/pgsql-hackers/2003-08/msg00937.php. It
implements new backend functionality (index scan cost estimation using
index correlation) and needs a new system table (pg_indexstat) to
work. I wouldn't call it perfect (for example, I still don't know how
to insert the new table into template0), but at least it shows that
there is a class of problems that require catalog changes and *can* be
solved without initdb.

Servus
Manfred