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

From Robert Haas
Subject Re: [WIP] In-place upgrade
Date
Msg-id 603c8f070811040801x13031ba4sa07a8024ea29644c@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] In-place upgrade  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [WIP] In-place upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [WIP] In-place upgrade  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
> We've talked about this many times before, so I'm sure you know what my
> opinion is. Let me phrase it one more time:
>
> 1. You *will* need a function to convert a page from old format to new
> format. We do want to get rid of the old format pages eventually, whether
> it's during VACUUM, whenever a page is read in, or by using an extra
> utility. And that process needs to online. Please speak up now if you
> disagree with that.

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,
but in the meantime you can still continue to read the old pages
without being forced to change them to the new format.  That's not the
only possible approach, but it's not obvious to me that it's insane.
If you think it's a non-starter, it would be good to know why.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle
Next
From: Bruce Momjian
Date:
Subject: Re: libpq and sslmode=require