Re: Protocol forced to V2 in low-memory conditions? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Protocol forced to V2 in low-memory conditions?
Date
Msg-id 5230B806.8040800@dunslane.net
Whole thread Raw
In response to Re: Protocol forced to V2 in low-memory conditions?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Protocol forced to V2 in low-memory conditions?
Re: Protocol forced to V2 in low-memory conditions?
List pgsql-hackers
On 09/11/2013 02:30 PM, Robert Haas wrote:
> On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote:
>>>> On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>> I've been thinking of late that it might be time to retire libpq's
>>>>> support for V2 protocol (other than in the specific context of the first
>>>>> error message received while trying to make a connection).
>>>> It's probably worth polling for that. I believe the jdbc driver at
>>>> least has code for it, but I don't know if it's a requirement at this
>>>> point.
>>> Yes, it has code for it and I think it's still used pretty frequently to
>>> circumvent prepared statement planning problems (misestimation,
>>> indeterminate types). So I think we need convincing reasons to break
>>> their usage.
>> Note that I was proposing removing libpq's support for V2 connections.
>> Not the backend's.
> I vote against this.  If we remove V2 support from libpq, then we'll
> have no easy way to test that the backend's support still works.  And
> we've got too many people using V2 to think that it's OK not to have
> an easy way of testing that.  I think the question we ought to be
> asking is: how can we get widely-used connectors to stop relying on V2
> in the first place?
>



How is it tested now, and who is doing the testing?

cheers

andrew




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Protocol forced to V2 in low-memory conditions?
Next
From: Josh Berkus
Date:
Subject: Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers