Re: Proposal: Multiversion page api (inplace upgrade)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Multiversion page api (inplace upgrade)
Date: 2008-06-11 15:15:06
Message-ID: 7463.1213197306@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> (this won't come as a surprise as we talked about this in PGCon, but) I
> think we should rather convert the page structure to new format in
> ReadBuffer the first time a page is read in. That would keep the changes
> a lot more isolated.

The problem is that ReadBuffer is an extremely low-level environment,
and it's not clear that it's possible (let alone practical) to do a
conversion at that level in every case. In particular it hardly seems
sane to expect ReadBuffer to do tuple content conversion, which is going
to be practically impossible to perform without any catalog accesses.

Another issue is that it might not be possible to update a page for
lack of space. Are we prepared to assume that there will never be a
transformation we need to apply that makes the data bigger? (Likely
counterexample: adding collation info to text values.) In such a
situation an in-place update might be impossible, and that certainly
takes it outside the bounds of what ReadBuffer can be expected to manage.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-06-11 15:35:17 Re: Proposal: Multiversion page api (inplace upgrade)
Previous Message Heikki Linnakangas 2008-06-11 14:59:06 Re: Proposal: Multiversion page api (inplace upgrade)