Re: State of Beta 2
От | Manfred Koizar |
---|---|
Тема | Re: State of Beta 2 |
Дата | |
Msg-id | 0e2nmvo3k146usq79acfh4r5o9dmuqrdnk@email.aon.at обсуждение исходный текст |
Ответ на | Re: State of Beta 2 (Dennis Gearon <gearond@fireserve.net>) |
Ответы |
Re: State of Beta 2
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-general |
On Fri, 19 Sep 2003 17:38:13 -0400, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-general по дате отправления: