Re: pgsql: libpq: Notice errors a backend may have sent just before dying.
| От | Michael Paquier |
|---|---|
| Тема | Re: pgsql: libpq: Notice errors a backend may have sent just before dying. |
| Дата | |
| Msg-id | CAB7nPqTCqfOFx_b=duf4Y8Vsbk4nE0M8N07pDD3GcM6nuCvb3Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgsql: libpq: Notice errors a backend may have sent just before dying. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-committers |
On Fri, Nov 13, 2015 at 1: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 ... Interesting lesson. Thanks! -- Michael
В списке pgsql-committers по дате отправления: