Re: pg_dump versus ancient server versions - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> Right. Well, we could leave it up to people who care to decide how
> much work they want to do, perhaps. But I do find it annoying that
> pg_dump is supposed to maintain compatibility with server releases
> that I can't easily build. Fortunately I don't patch pg_dump very
> often, but if I did, it'd be very difficult for me to verify that
> things work against really old versions. I know that you (Tom) do a
> lot of work of this type though. In my opinion, if you find yourself
> working on a project of this type and as part of that you do some
> fixes to an older branch to make it compile, maybe you ought to commit
> those so that the next person doesn't have the same problem.

Well, the answer to that so far is that I've never done such fixes.
I have the last released versions of old branches laying around,
and that's what I test against.  It's been sufficient so far, although
if I suddenly needed to do (say) SSL-enabled testing, that would be
a problem because I don't think I built with SSL for any of those
branches.

Because of that angle, I concur with your position that it'd really
be desirable to be able to build old versions on modern platforms.
Even if you've got an old executable, it might be misconfigured for
the purpose you have in mind.

> And maybe
> when we add support for newer versions of OpenSSL or Windows, we ought
> to consider back-patching those even to unsupported releases if
> someone's willing to do the work. If they're not, they're not, but I
> think we tend to strongly discourage commits to EOL branches, and I
> think maybe we should stop doing that. Not that people should
> routinely back-patch bug fixes, but stuff that makes it easier to
> build seems fair game.

What concerns me here is that we not get into a position where we're
effectively still maintaining EOL'd versions.  Looking at the git
history yesterday reminded me that we had such a situation back in
the early 7.x days.  I can see that I still occasionally made commits
into 7.1 and 7.2 years after the last releases of those branches,
which ended up being a complete waste of effort.  There was no policy
guiding what to back-patch into what branches, partly because we
didn't have a defined EOL policy then.  So I want to have a policy
(and a pretty tight one) before I'll go back to doing that.

Roughly speaking, I think the policy should be "no feature bug fixes,
not even security fixes, for EOL'd branches; only fixes that are
minimally necessary to make it build on newer platforms".  And
I want to have a sunset provision even for that.  Fixing every branch
forevermore doesn't scale.

There's also the question of how we get to a working state in the
first place -- as we found upthread, there's a fair-sized amount
of work to do just to restore buildability right now, for anything
that was EOL'd more than a year or two back.  I'm not volunteering
for that, but somebody would have to to get things off the ground.

Also, I concur with Andrew's point that we'd really have to have
buildfarm support.  However, this might not be as bad as it seems.
In principle we might just need to add resurrected branches back to
the branches_to_build list.  Given my view of what the back-patching
policy ought to be, a new build in an old branch might only be
required a couple of times a year, which would not be an undue
investment of buildfarm resources.  (Hmmm ... but disk space could
become a problem, particularly on older machines with not so much
disk.  Do we really need to maintain a separate checkout for each
branch?  It seems like a fresh checkout from the repo would be
little more expensive than the current copy-a-checkout process.)

            regards, tom lane