Re: pg_dump getBlobs query broken for 7.3 servers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump getBlobs query broken for 7.3 servers
Date: 2016-10-12 22:42:31
Message-ID: CA+TgmoYU6Sg0cbjCn7bZOL3ZPgJz=GY5_XkpwCqRU_4tAevGpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 12, 2016 at 12:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
>>> Fwiw I was considering proposing committing some patches for these old
>>> releases to make them easier to build. I would suggest creating a tag
>>> for a for this stable legacy version and limiting the commits to just:
>>>
>>> 1) Disabling warnings
>>> 2) Fixing bugs in the configure scripts that occur on more recent
>>> systems (version number parsing etc)
>>> 3) Backporting things like the variable-length array code that prevents building
>>> 4) Adding compiler options like -fwrapv
>
>> I'd support that. The reason why we remove branches from support is
>> so that we don't have to back-patch things to 10 or 15 branches when
>> we have a bug fix. But that doesn't mean that we should prohibit all
>> commits to those branches for any reason, and making it easier to test
>> backward-compatibility when we want to do that seems like a good
>> reason.
>
> Meh, I think that this will involve a great deal more work than it's
> worth. We deal with moving-target platforms *all the time*. New compiler
> optimizations break things, libraries such as OpenSSL whack things around,
> other libraries such as uuid-ossp stop getting maintained and become
> unusable on new platforms, bison decides to get stickier about comma
> placement, yadda yadda yadda. How much of that work are we going to
> back-port to dead branches? And to what extent is such effort going to be
> self-defeating because the branch no longer behaves as it did back in the
> day?
>
> If Greg wants to do this kind of work, he's got a commit bit. My position
> is that we have a limited support lifespan for a reason, and I'm not going
> to spend time on updating dead branches forever. To me, it's more useful
> to test them in place on contemporary platforms. We've certainly got
> enough old platforms laying about in the buildfarm and elsewhere.

I agree that it shouldn't be an expectation that committers in general
will do this, whether you or me or anyone else. However, I think that
if Greg or some other committer wants to volunteer their own time to
do some of it, that is fine.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2016-10-12 23:03:17 Re: munmap() failure due to sloppy handling of hugepage size
Previous Message Andres Freund 2016-10-12 22:23:35 Re: munmap() failure due to sloppy handling of hugepage size