Re: pgsql: libpq: Notice errors a backend may have sent just before dying.
От | Tom Lane |
---|---|
Тема | Re: pgsql: libpq: Notice errors a backend may have sent just before dying. |
Дата | |
Msg-id | 30762.1447347280@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: libpq: Notice errors a backend may have sent just before dying. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: libpq: Notice errors a backend may have sent
just before dying.
Re: pgsql: libpq: Notice errors a backend may have sent just before dying. |
Список | 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
В списке pgsql-committers по дате отправления: