Re: pg_upgrade: How to deal with toast - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: pg_upgrade: How to deal with toast
Date
Msg-id 492510DB.6040400@sun.com
Whole thread Raw
In response to Re: pg_upgrade: How to deal with toast  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: pg_upgrade: How to deal with toast  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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 by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Hot Standby (commit fest version - v5)
Next
From: "Harald Armin Massa"
Date:
Subject: Re: Cool hack with recursive queries