Re: In-place upgrade: catalog side - Mailing list pgsql-hackers

From Robert Haas
Subject Re: In-place upgrade: catalog side
Date
Msg-id 603c8f070812041427r2ab3eedevf33d4fb337104367@mail.gmail.com
Whole thread Raw
In response to Re: In-place upgrade: catalog side  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
> Not being familiar with the code, my assumption was that it would be
> possible to push all the tuples involved off to another page as if they'd
> been updated, with WAL logging and everything, similarly to the ideas that
> keep getting kicked around for creating extra space for header expansion.
> Almost the same code really, just with the target of moving everything that
> references the dead column rather than moving just enough to create the
> space needed.  Actually doing the upgrade on the page itself does seem quite
> perilous.

For in-place upgrade, you can tell which pages have been converted and
which have not by looking at the page header, so you can put a switch
into the code to handle each version appropriately.  I don't think
that would be possible in this case without purpose-built
infrastructure.  It might be possible to lock out writers only and
rewrite the table in a new file though, disk space permitting.

...Robert


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Simple postgresql.conf wizard
Next
From: Kevin Neufeld
Date:
Subject: Re: [postgis-devel] CLUSTER in 8.3 on GIST indexes break