Re: BUG #10141: Server fails to send query result.
От | Tom Lane |
---|---|
Тема | Re: BUG #10141: Server fails to send query result. |
Дата | |
Msg-id | 13193.1398453615@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #10141: Server fails to send query result. (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: BUG #10141: Server fails to send query result.
|
Список | pgsql-bugs |
Stephen Frost <sfrost@snowman.net> writes: > * molind@gmail.com (molind@gmail.com) wrote: >> I added PQtrace for each thread and wait for stuck thread. There is trace: >> From backend> D >> From backend (#4)> 139891 >> From backend> D >> From backend (#4)> 139891 >> From backend> D >> From backend (#4)> 139891 >> From backend> D >> From backend (#4)> 139891 >> From backend> D >> From backend (#4)> 139891 >> From backend> D >> From backend (#4)> 139891 FWIW, this looks suspiciously like libpq is unable to consume data from its input buffer (and keeps retrying to process the same data). Are you using PQsetnonblocking by any chance? If so, this probably indicates failure to follow the required call sequencing to process data. Another likely theory, given that you mentioned multiple client threads, is that the threads are stomping on each others' toes somehow. libpq does not defend itself against that: it's up to you to be sure that only one thread is touching each PGconn object. >> Seems problem somewhere inside PostgreSQL. It tries to send result but >> fails. > I don't see anything here which shows that to be the case. Indeed. I'd bet considerable money that this is a client-side issue. It's possible that it's a libpq bug, but what seems more likely is that you're using libpq improperly. regards, tom lane
В списке pgsql-bugs по дате отправления: