Martijn van Oosterhout wrote:
> On Tue, Jul 03, 2007 at 09:51:59PM -0400, Tom Lane wrote:
>> Out-of-line datums aren't the only issue, either: consider inline
>> compressed datums. A data representation change, even one that is known
>> not to increase the ordinary uncompressed size of the datum, could
>> easily render it slightly less compressible, resulting in a risk that
>> the tuple doesn't fit on the page anymore. It hardly seems practical
>> (maybe not even possible) to guarantee that this cannot happen.
>
> Does the converted page have to fit into a single page? It's a bit of a
> corner-case, there's slack on every page. Wouldn't it be possible to
> replace an oversize tuple with a pointer to a new tuple on a new page
> (indexes are the problem here).
I think it is same problem as Tom mentioned about catalog access which
you probably need for handle index modification. I have some wild idea
how to handle, but it needs more experiments.
>> So maybe we are up against the conclusion that in-place updates cannot
>> support datatype representation changes, at least not for toastable
>> datatypes. We could still handle 'em by the expedient suggested
>> upthread for user-defined types, ie the "new representation" is treated
>> as a whole new type. That's not terribly appetizing though; I had
>> expected we could be more efficient for the case of changes in built-in
>> types.
>
> Well, it seems to me 99% of cases can be handled easily, we just might
> have to have a backup method for the cases where the simple cases
> doesn't work...
The question is how to check if database is fit in 1% of corner cases.
One suggested solution was to run preupgrade check on old version, but
it also generates problem how to avoid "ugly" modification of already
checked pages.
Zdenek
