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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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-12 16:54:40
Message-ID: 30762.1447347280@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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 ...

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2015-11-12 18:04:01 pgsql: Fix unwanted flushing of libpq's input buffer when socket EOF is
Previous Message Tom Lane 2015-11-12 16:25:18 Re: pgsql: libpq: Notice errors a backend may have sent just before dying.