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

From Tom Lane
Subject Re: [WIP] In-place upgrade
Date
Msg-id 15637.1226007729@sss.pgh.pa.us
Whole thread Raw
In response to Re: [WIP] In-place upgrade  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: [WIP] In-place upgrade  (Greg Smith <gsmith@gregsmith.com>)
Re: [WIP] In-place upgrade  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Adding catalog columns seems rather complicated, and not back-patchable. 

Agreed, we'd not be able to make them retroactively appear in 8.3.

> I imagined that you would have just a single cluster-wide variable, a 
> GUC perhaps, indicating how much space should be reserved by 
> updates/inserts. Then you'd have an additional program, perhaps a new 
> contrib module, that sets the variable to the right value for the 
> version you're upgrading, and scans through all tables, moving tuples so 
> that every page has enough free space for the upgrade. After that's 
> done, it'd set a flag in the data directory indicating that the cluster 
> is ready for upgrade.

Possibly that could work.  The main thing is to have a way of being sure
that the prep work has been completed on every page of the database.
The disadvantage of not having catalog support is that you'd have to
complete the entire scan operation in one go to be sure you'd hit
everything.

Another thought here is that I don't think we are yet committed to any
changes that require extra space between 8.3 and 8.4, are we?  The
proposed addition of CRC words could be put off to 8.5, for instance.
So it seems at least within reach to not require any preparatory steps
for 8.3-to-8.4, and put the infrastructure in place now to support such
steps in future go-rounds.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [WIP] In-place upgrade
Next
From: Josh Berkus
Date:
Subject: Final /contrib cleanup -- yes/no?