Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I envision a similar system where we have utilities to guarantee all
> > pages have enough free space, and all pages are the current version,
> > before allowing an upgrade-in-place to the next version. Such a
> > consistent API will make the job for users easier and our job simpler,
> > and with upgrade-in-place, where we have limited time and resources to
> > code this for each release, simplicity is important.
>
> An external utility doesn't seem like the right way to approach it.
> For example, given the need to ensure X amount of free space in each
> page, the only way to guarantee that would be to shut down the database
> while you run the utility over all the pages --- otherwise somebody
> might fill some page up again. And that completely defeats the purpose,
> which is to have minimal downtime during upgrade.
>
> I think we can have a notion of pre-upgrade maintenance, but it would
> have to be integrated into normal operations. For instance, if
> conversion to 8.4 requires extra free space, we'd make late releases
> of 8.3.x not only be able to force that to occur, but also tweak the
> normal code paths to maintain that minimum free space.
>
> The full concept as I understood it (dunno why Bruce left all these
> details out of his message) went like this:
Exactly. I didn't go into the implementation details to make it easer
for people to see my general goals. Tom's implementation steps are the
correct approach, assuming we can get agreement on the general goals.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +