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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
