Re: Hardening pg_upgrade - Mailing list pgsql-hackers

On Mon, Aug 25, 2014 at 3:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> OK, I will move in the direction of removing 8.3 support and use a
>> single query to pull schema information.   I was hesistant to remove 8.3
>> support as I know we have kept pg_dump support all the way back to 7.0,
>> but it seems pg_upgrade need not have the same version requirements.
>
> Not really related, but ... I've been thinking that it's time to rip out
> pg_dump's support for server versions before 7.3 or 7.4.  That would let
> us get rid of a lot of klugy code associated with the lack of schemas
> and dependency info in the older versions.  It's possible that we should
> move the cutoff even further --- I've not looked closely at how much could
> be removed by dropping versions later than 7.3.
>
> Aside from the question of how much old code could be removed, there's the
> salient point of how do we test pg_dump against such old branches?  The
> further back you go the harder it is to even build PG on modern platforms,
> and the less likely it will work (I note for example that pre-8.0
> configure doesn't try to use -fwrapv, let alone some of the other switches
> we've found necessary on recent gcc).  I've usually tested pg_dump patches
> against old servers by running them against builds I have in captivity on
> my old HPPA box ... but once that dies, I'm *not* looking forward to
> trying to rebuild 7.x on my current machines.

I think it's fine for us to start requiring two-step upgrades beyond a
certain point, and I think removing pg_dump support for pre-7.4
versions of the server is very reasonable.  I also think removing
pg_upgrade support for 8.3 is reasonable.  Many products require
multi-step upgrades when crossing multiple release versions, and I
think we can, too.

Having said that, there are obviously advantages for our users if we
don't get too crazy about requiring that.  I've used products in the
past where to get from version 3 to version 11 you have to upgrade
from 3 to 5, then 5 to 7, then 7 to 9, and then 9 to 11.  That's
somewhat understandable from the vendor's point of view, but it's not
a lot of fun, and I think we should definitely avoid imposing those
kinds of requirements on our users.

What we're talking about here is much milder than that.  For the
pg_upgrade case, you can upgrade from 8.3 to any of 8.4, 9.0, 9.1,
9.2, 9.3, and 9.4.  You only need to do a two-step upgrade if you want
to leapfrog more than 6 major release versions.  That seems like a
wide-enough window that it shouldn't inconvenience many people.  For
the pg_dump case, you can upgrade from 7.2 or 7.3 to 7.4, 8.0, 8.1,
8.2, 8.3, 8.4, 9.0, 9.1, 9.2, 9.3, or 9.4; that is, 11 or 12 major
releases.  The number of people who want to skip more than a dozen
releases in a single upgrade should be very small, and we might
council those people that they'd be better off with a step-wise
upgrade for other reasons - like the application-level compatibility
breaks we've made over the years - anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company