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

From Robert Haas
Subject Re: Protocol forced to V2 in low-memory conditions?
Date
Msg-id CA+Tgmobct5i1QtcV4vGNyh2cFd-0ykJkNHUxOxfZFZuYbWzM-Q@mail.gmail.com
Whole thread Raw
In response to Re: Protocol forced to V2 in low-memory conditions?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 8, 2013 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ still catching up on old email ]
>
> I wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> 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:
>>>>> 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.
>
>>> How is it tested now, and who is doing the testing?
>
>> Exactly.  The current support in libpq is nigh useless for testing
>> purposes, because there's no way to activate that code path on command.
>> It only runs if libpq (thinks it) is connecting to a pre-7.4 backend.
>
> Actually ... there's another way we might deal with this.  Suppose we
> invent a libpq connection option to specify whether to use v2 or v3
> protocol, defaulting to the latter, and then just remove the protocol-
> fallback-during-connection code path.  If there is anyone out there using
> a modern libpq to talk to a pre-7.4 server, they can be told to invoke
> the connection option.  This gets rid of the unexpected-protocol-downgrade
> problem in a reliable manner, and it also gives us a way to test V2 code
> paths in both libpq and the backend, which Andrew is correct to finger as
> something that goes nearly totally untested right now.
>
> The main objections I can see to this are (1) it wouldn't provide
> a back-patchable fix, and (2) it'd be adding more legacy code instead
> of removing it.  But the other approaches that we've talked about didn't
> sound very back-patchable either, so I think only (2) really holds
> much water.

This approach sounds promising to me.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Protocol forced to V2 in low-memory conditions?
Next
From: Robert Haas
Date:
Subject: Re: logical changeset generation v6.5