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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Is it time to kill support for very old servers?
Дата
Msg-id 20170914050605.olukgqkyptkklaak@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Is it time to kill support for very old servers?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Optimise default partition scanning while adding newpartition
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] psql: new help related to variables are not tooreadable