Re: pgsql: libpq: Notice errors a backend may have sent just before dying. - Mailing list pgsql-committers

From Robert Haas
Subject Re: pgsql: libpq: Notice errors a backend may have sent just before dying.
Date
Msg-id CA+TgmoaS2twJ2dtM=wv52p+2gqFDqWqWrf2MjG75bzG_42-P2Q@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: libpq: Notice errors a backend may have sent just before dying.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On Thu, Nov 12, 2015 at 11:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> After looking around, I suspect what actually happened in your test
>> was that we kept pumping pqReadData until it realized it was seeing EOF,
>> whereupon it did pqDropConnection(), and guess what that does:
>
>>       /* Discard any unread/unsent data */
>>       conn->inStart = conn->inCursor = conn->inEnd = 0;
>>       conn->outCount = 0;
>
> So after further review, this is a bug I introduced in 210eb9b74:
> the fact that some code paths flushed the buffers and some did not
> was less of an oversight than it appeared.  That explains why the
> problem wasn't noticed years ago, because we'd certainly tested
> pqHandleSendFailure and friends before.
>
> I'm inclined to deal with this by adding a "dropInput" boolean flag
> to pqDropConnection(), rather than reverting the centralization of
> that logic altogether.
>
> I'll go clean this up ...

Thanks.  I guess I should have studied this more deeply.

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


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Fix unwanted flushing of libpq's input buffer when socket EOF is
Next
From: pgsql@postgresql.org
Date:
Subject: pgsql: Tag refs/tags/REL9_5_BETA2 was created