Re: pgsql: libpq: Notice errors a backend may have sent just before dying.
От | Robert Haas |
---|---|
Тема | Re: pgsql: libpq: Notice errors a backend may have sent just before dying. |
Дата | |
Msg-id | CA+TgmoaS2twJ2dtM=wv52p+2gqFDqWqWrf2MjG75bzG_42-P2Q@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 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 по дате отправления: