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
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 |