Re: pg_upgrade: How to deal with toast

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: pg_upgrade: How to deal with toast
Дата
Msg-id 492510DB.6040400@sun.com
обсуждение исходный текст
Ответ на Re: pg_upgrade: How to deal with toast  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: pg_upgrade: How to deal with toast  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:
>> 2) data type is unknown
>>
>> Unfortunately, in low function is no clue what data type is really 
>> stored in a chunks.
> 
> Do we need to know? We haven't changed the on-disk format of any data 
> types between 8.3 and 8.4, have we?

Yeah, there is no change, but we should prepare on-disk format for any potential 
future change.

> The other idea that was suggested earlier is to retoast all toast datums 
> referenced from the heap page, when the heap page is read in. We know 
> the data types at that point. That generates a lot more random I/O on 
> the first access to the unconverted heap page, but I think it would be ok.

Thanks to remind me this approach. Yeah it is solution which should work. I 
don't like much this because random I/O, however this could be used for chunk 
record transformation between 8.3->8.4. And after that we will be able converted 
it on detoast request.

The question is if we should do toast modification now to avoid potential future 
problems or if we will solve it when any on-disk format change requires it?

I prefer do it now, because there could be small risk that it will not possible 
to do it in the future. When in-place upgrade will be implemented nobody will 
want to perform backup/restore.

    thanks Zdenek



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

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Hot Standby (commit fest version - v5)
Следующее
От: "Harald Armin Massa"
Дата:
Сообщение: Re: Cool hack with recursive queries