Re: Proposal: Multiversion page api (inplace upgrade) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: Multiversion page api (inplace upgrade)
Date
Msg-id 7463.1213197306@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: Multiversion page api (inplace upgrade)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: Proposal: Multiversion page api (inplace upgrade)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Proposal: Multiversion page api (inplace upgrade)  (Gregory Stark <stark@enterprisedb.com>)
Re: Proposal: Multiversion page api (inplace upgrade)  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
"Heikki Linnakangas" <heikki@enterprisedb.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


pgsql-hackers by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: Proposal: Multiversion page api (inplace upgrade)
Next
From: Zdenek Kotala
Date:
Subject: Re: Proposal: Multiversion page api (inplace upgrade)