From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com |
Subject: | Let's drop V2 protocol |
Date: | 2012-02-24 13:52:10 |
Message-ID: | 20120224135210.GA11282@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?"
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Shulgin | 2012-02-24 13:52:51 | Re: Reviewing patch "URI connection string support for libpq" |
Previous Message | Kohei KaiGai | 2012-02-24 13:20:25 | Re: [v9.2] Add GUC sepgsql.client_label |