From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Protocol forced to V2 in low-memory conditions? |
Date: | 2013-11-08 19:23:48 |
Message-ID: | 23828.1383938628@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[ still catching up on old email ]
I wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 09/11/2013 02:30 PM, Robert Haas wrote:
>>> On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-11-08 20:02:30 | pgsql: Fix pg_isolation_regress to work outside its build directory. |
Previous Message | Tom Lane | 2013-11-08 18:43:14 | Re: pgsql: Fix blatantly broken record_image_cmp() logic for pass-by-value |