Re: [WIP] In-place upgrade - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [WIP] In-place upgrade
Date
Msg-id 603c8f070811041949y7964c507wded15c6a5f583480@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
>> Maybe.  The difference is that I'm talking about converting tuples,
>> not pages, so "What happens when the data doesn't fit on the new
>> page?" is a meaningless question.
>
> No it's not, because as you pointed out you still need a way for the user to
> force it to happen sometime. Unless you're going to be happy with telling
> users they need to update all their tuples which would not be an online
> process.
>
> In any case it sounds like you're saying you want to allow multiple versions
> of tuples on the same page -- which a) would be much harder and b) doesn't
> solve the problem since the page still has to be converted sometime anyways.

No, that's not what I'm suggesting.  My thought was that any V3 page
would be treated as if it were completely full, with the exception of
a completely empty page which can be reinitialized as a V4 page.  So
you would never add any tuples to a V3 page, but you would need to
update xmax, hint bits, etc.  Eventually when all the tuples were dead
you could reuse the page.

...Robert


pgsql-hackers by date:

Previous
From: "Vladimir Sitnikov"
Date:
Subject: Re: Windowing Function Patch Review -> Standard Conformance
Next
From: Gregory Stark
Date:
Subject: Re: [WIP] In-place upgrade