Re: pg_dump getBlobs query broken for 7.3 servers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 19:02:53
Message-ID: CA+TgmoYiQ0qDEL0evp7xO8i0wMxfkm4mD0SFfug86Pdhuqmtmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Mon, Oct 10, 2016 at 9:52 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>>
>> The code is here:
>>
>> https://github.com/gsstark/retropg
>>
>> The build script is called "makeall" and it applies patches from the
>> "old-postgres-fixes" directory though some of the smarts are in the
>> script because it knows about how to run older version of the
>> configure script and it tries to fix up the ecpg parser duplcate
>> tokens separately. It saves a diff after applying the patches and
>> other fixups into the "net-diffs" directory but I've never checked if
>> those diffs would work cleanly on their own.
>
>
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-10-12 19:05:11 Re: Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Robert Haas 2016-10-12 18:59:45 Re: Non-empty default log_line_prefix