Re: Proposal: In-Place upgrade concept

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: In-Place upgrade concept
Date: 2007-07-04 01:51:59
Message-ID: 16489.1183513919@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I do have an objection though: TOAST data. Even were the bufmgr to be
> provided with a mechanism to find a data type conversion function I
> don't see what it would do about a toasted datum.

Urgh, that *is* a nasty thought :-(

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-07-04 02:35:31 Why so many out-of-disk-space failures on buildfarm machines?
Previous Message Gregory Stark 2007-07-04 01:06:55 Re: Proposal: In-Place upgrade concept