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

From Gregory Stark
Subject Re: [WIP] In-place upgrade
Date
Msg-id 87skq75e4g.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [WIP] In-place upgrade  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: [WIP] In-place upgrade  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:

>>> Well, I just proposed an approach that doesn't work this way, so I
>>> guess I'll have to put myself in the disagree category, or anyway yet
>>> to be convinced.  As long as you can move individual tuples onto new
>>> pages, you can eventually empty V3 pages and reinitialize them as new,
>>> empty V4 pages.  You can force that process along via, say, VACUUM,
>>
>> No, if you can force that process along via some command, whatever it is, then
>> you're still in the category he described.
>
> 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.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: "David Rowley"
Date:
Subject: Re: Windowing Function Patch Review -> Performance Comparison.
Next
From: Bruce Momjian
Date:
Subject: Re: libpq and sslmode=require