On 2/29/12 3:53 PM, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of mié feb 29 18:34:27 -0300 2012:
Robert Haas<robertmh...@gmail.com> writes:
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
The utility would run in the old cluster before upgrading, so the the flag
would have to be present in the old version. pg_upgrade would check that the
flag is set, refusing to upgrade if it isn't, with an error like "please run
pre-upgrade utility first".
I find that a pretty unappealing design; it seems to me it'd be much
easier to make the new cluster cope with everything.
Easier for who? I don't care for the idea of code that has to cope with
two page formats, or before long N page formats, because if we don't
have some mechanism like this then we will never be able to decide that
an old data format is safely dead.
.. in fact this is precisely what killed Zdenek Kotala's idea of
upgrading.
This is also why Simon has avoided the whole upgrade thing with his 16 bit
checksum idea (otherwise presumably we'd be looking at bigger checksums anyway).
I get that fussing around with the version field is ugly. If there was another
way to do this without breaking pg_upgrade then it would be silly to mess with
the version field. Unfortunately, there is no other way.
Page checksuming is something a lot of people (myself included) want to see.
Being able to get it in 9.2 would be a big win over crossing our fingers that
at some point in the future (who knows when) we'll maybe figure out the page
format upgrade issue. While we should definitely be looking into that issue
it's definitely not going to get fixed in 9.2. ISTM that checksums are actually
ready to go if people can just swallow the bitter pill of a screwed-up page
version field until we can actually get an upgrade utility in place (and until
we get that utility in place I don't see that the version field would do us any
good anyway...)
--
Jim C. Nasby, Database Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
