Re: In-place upgrade: catalog side

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: In-place upgrade: catalog side
Date: 2008-12-04 22:27:12
Message-ID: 603c8f070812041427r2ab3eedevf33d4fb337104367@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Neufeld 2008-12-04 22:42:57 Re: [postgis-devel] CLUSTER in 8.3 on GIST indexes break
Previous Message Kevin Grittner 2008-12-04 22:15:01 Re: Simple postgresql.conf wizard