Greg Smith napsal(a):
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.
The TOAST problem is already addressed and script should handle it correctly.
But I don't like it much, because it is kind of magic.
Dropped column is another story. Heikki pointed me this issue in Prato and
current published version of script does not handle it. Problem is that dropped
columns are only mark as a deleted and data are still stored in tuples. Catalog
contains related information about position and length, but when you perform
dump and restore, this information is lost and columns are shifted ...
I already added to check for dropped column and now I'm going to test how
upgrade works with visibility map. I'll send this version when I finish tests.
<snip>
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.
I agree. This is a starter for 8.3 -> 8.4, but we need more robust solution in
the future.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
