Re: pgsql: libpq: Notice errors a backend may have sent just before dying.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: libpq: Notice errors a backend may have sent just before dying.
Date: 2015-11-13 01:24:46
Message-ID: CAB7nPqTCqfOFx_b=duf4Y8Vsbk4nE0M8N07pDD3GcM6nuCvb3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Fri, Nov 13, 2015 at 1:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 ...

Interesting lesson. Thanks!
--
Michael

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Stephen Frost 2015-11-13 16:07:00 pgsql: Correct sepgsql docs with regard to RLS
Previous Message Alvaro Herrera 2015-11-12 21:22:26 pgsql: vacuumdb: don't prompt for passwords over and over