On Wed, 3 Dec 2008, Zdenek Kotala wrote:
It works fine for 8.3->8.4 too, but I'm working on cleanup and fixing bugs. I hope that I will send updated version to community today.
That would be great. It didn't feel like you were quite done with it yet. I'll be glad to help test it out, just didn't want to jump into that if it was known to still have issues that were being worked on. Please let us know what the remaining bugs you know about are at that point, I really don't want this part of things to get ignored just because the page format stuff is the harder part.
It is more workaround or temporary solution. This approach is easy but it has lot of limitation. Problem with toast tables is one, but biggest problem is with dropped columns. And maybe there will be more issues. Problem with dump is that you lost a internal data.
Can you be a bit more specific about what the problems with TOAST and dropped columns are? If those are covered in your presentation or came up already and I missed it, just point me that way; I'm still working my way through parts of this and don't expect to ever have it all in my head like you do at this point. Obviously this approach is going to be somewhat traumatic even if perfectly executed because of things like losing table statistics.
As we move closer to final crunch time here, what I am trying to keep clear in my head is which bits are absolutely required to do any type of in-place upgrade, whether or not the page format changes in 8.4. What's nice is that those parts I can be testing right now just by trying to upgrade from 8.3 to 8.4. Barring things like the TOAST problem you mention getting in the way, the fundamental approach taken by these upgrade scripts seems workable for the job even it's not optimal, and that's a whole lot better than nothing at all.
I personally prefer to have special mode (like boostrap) which converts data from old catalog to new format.
That's a perfectly fine idea I would like to see too. But if we have to write such a thing from scratch right now, I'm afraid that may be too late to implement and still ship the next release on schedule. And if such bootstrap code is needed, we sure need to make sure the prototype it's going to be built on is solid ASAP. That's what I want to help you look into if you can catch me up a bit here.
-- * Greg Smith [EMAIL PROTECTED] 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
