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
