Re: [WIP] In-place upgrade - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [WIP] In-place upgrade
Date
Msg-id 603c8f070811061240i2b8d98a4ja5f5d68492208a9f@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] In-place upgrade  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [WIP] In-place upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> And almost guarantee that the job will never be completed, or tested
> fully.  Remember that in-place upgrades would be pretty painless so
> doing multiple major upgrades should not be a difficult requiremnt, or
> they can dump/reload their data to skip it.

Regardless of what design is chosen, there's no requirement that we
support in-place upgrade from 8.3 to 8.6, or even 8.4 to 8.6, in one
shot.  But the design that you and Tom are proposing pretty much
ensures that it will be impossible.

But that's certainly the least important reason not to do it this way.I think this comment from Heikki is pretty
revealing:

> Adding catalog columns seems rather complicated, and not back-patchable. Not backpatchable means that we'd need to be
surenow
 
> that the format serial numbers are enough for the upcoming 8.4-8.5 upgrade.

That means, in essence, that the earliest possible version that could
be in-place upgraded would be an 8.4 system - we are giving up
completely on in-place upgrade to 8.4 from any earlier version (which
personally I thought was the whole point of this feature in the first
place).  And we'll only be able to in-place upgrade to 8.5 if the
unproven assumption that these catalog changes are sufficient turns
out to be true, or if whatever other changes turn out to be necessary
are back-patchable.

...Robert


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [WIP] In-place upgrade
Next
From: Tom Lane
Date:
Subject: Re: BufferAccessStrategy for bulk insert