Skip site navigation (1) Skip section navigation (2)

Re: Let's drop V2 protocol

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, shigeru(dot)hanada(at)gmail(dot)com
Subject: Re: Let's drop V2 protocol
Date: 2012-02-24 14:26:36
Message-ID: CAHyXU0wwR_nQZ3Dy+ZjCQ9_tr9E3FLRz_JAmP2y8gem8cYAj0w@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb 24, 2012 at 7:52 AM, Marko Kreen <markokr(at)gmail(dot)com> wrote:
> On Fri, Feb 24, 2012 at 02:11:45PM +0200, Marko Kreen wrote:
>> On Fri, Feb 24, 2012 at 07:53:14PM +0900, Kyotaro HORIGUCHI wrote:
>> > - I have no idea how to do test for protocol 2...
>>
>> I have a urge to test with "rm fe-protocol2.c"...
>
> Now I tested with 7.3.21 and the non-error case works fine.  Error state
> does not - and not because patch is buggy, but because it has never
> worked - V2 protocol has no working concept of skipping packets because
> pending error state.
>
> On OOM, V2 code does:
>
>   conn->inStart = conn->inEnd;
>
> and hopes for the best, but it does not work, because on short results
> it moves past ReadyForQuery, on long results it moves into middle of
> some packet.
>
> With user-specified row processor, we need to have a working
> error state handling.  With some surgery, it's possible to
> introduce something like
>
>   if (conn->result->resultStatus != PGRES_TUPLES_OK)
>
> into various places in the code, to ignore but still
> parse the packets.  But it will be rather non-trivial patch.
>
> So could we like, uh, not do it and simply drop the V2 code?
>
>
> Ofcourse, the row-processor patch does not make the situation worse,
> so we could just say "don't use custom row processor with V2 servers",
> but it still raises the question: "Does anyone have pre-7.4
> servers around and if yes, then why does he need to use 9.2 libpq
> to access those?"

I think it's plausible that very old client libraries could connect to
a modern server.  But it's pretty unlikely to have a 9.2 app contact
an ancient server IMO.

merlin

In response to

Responses

pgsql-hackers by date

Next:From: Yeb HavingaDate: 2012-02-24 14:40:24
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Previous:From: Yeb HavingaDate: 2012-02-24 14:17:12
Subject: Re: [v9.2] Add GUC sepgsql.client_label

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group