Re: Is it time to kill support for very old servers?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is it time to kill support for very old servers?
Date: 2017-09-14 05:06:05
Message-ID: 20170914050605.olukgqkyptkklaak@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Re-upping this topic.
>
> > On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
> >> In the same line, maybe we should kill libpq's support for V2 protocol
> >> (which would make the cutoff 7.4). And maybe the server's support too,
> >> though that wouldn't save very much code. The argument for cutting this
> >> isn't so much that we would remove lots of code as that we're removing
> >> code that never gets tested, at least not by us.
>
> > I'd like to do this in the not too far away future for at least the
> > backend. There's enough not particularly pretty code to deal with v2
> > that that'd be worthwhile.
>
> Hm, I don't recall that there's very much on the server side that could be
> saved --- what's incurring your ire, exactly?

In this specific instance it's SendRowDescriptionMessage() for a queries
returning a lot of columns that execute fast. The additional branches
due to the if (proto >= 3) conditionals are noticeable. It's easy enough
to fix by having two for() for the two cases. The added code is annoying
but bearable, what actually concerns me is that it's really hard to test
the v2 support.

> >> One small problem with cutting libpq's V2 support is that the server's
> >> report_fork_failure_to_client() function still sends a V2-style message.
>
> > We should really fix that so it reports the error as a v3 message,
> > independent of ripping out libpq-fe support for v2.
>
> It might be reasonable to do that, but libpq would have to be prepared
> for the other case for many years to come :-(

Right. But there seems pretty much no way to get around that. At least
none that I can see? It might be worthwhile and more testable to add a
special case V2 handling for the oom-fork case, but still.

> The real problem in this area, to my mind, is that we're not testing that
> code --- either end of it --- in any systematic way. If it's broken it
> could take us quite a while to notice.

Yea, that concerns me a lot too (see above).

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-09-14 05:15:40 Re: psql: new help related to variables are not too readable
Previous Message Amit Langote 2017-09-14 05:01:23 Re: Optimise default partition scanning while adding new partition