Re: In-place upgrade: catalog side

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: In-place upgrade: catalog side
Дата
Msg-id 49379BB9.6030200@sun.com
обсуждение исходный текст
Ответ на Re: In-place upgrade: catalog side  (Greg Smith <gsmith@gregsmith.com>)
Ответы Re: In-place upgrade: catalog side  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Fujii Masao"
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: V2 of PITR performance improvement for 8.4