Re: BUG #16007: Regarding patch for BUG #3995: pqSocketCheck doesn't return

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kiran Khatke <kirankhatke23may(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16007: Regarding patch for BUG #3995: pqSocketCheck doesn't return
Date: 2019-09-16 13:54:55
Message-ID: 31394.1568642095@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kiran Khatke <kirankhatke23may(at)gmail(dot)com> writes:
> One of the thread of DBMGR Daemon is waiting for the result of poll()
> function.
> poll() was called by pgSocketCheck(). So pqSocketCheck() didn't return,
> hung in poll().
> Below is the backtrace.

Well, it's waiting for the query to finish, or so it thinks. Did you
look at what the server thinks the session is doing?

Your reference to multiple threads is a red flag to me. Very often
we see people whose programs try to use the same PGconn object from
multiple threads. That doesn't work --- and libpq does not have any
internal mutexes that would prevent the object's state from getting
messed up by concurrent operations. So a plausible theory is that
this PGconn was used concurrently, and now this particular thread
is stuck because the object's state is corrupt (ie, it shows the
query as busy but the server doesn't think so).

It might be worth enabling log_statement = all on the server side
and then watching the server log to see what seems to be happening
from that end.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-09-17 09:27:57 BUG #16009: ERROR:  found xmax 1245512970 from before relfrozenxid 1245512975
Previous Message Peter Bex 2019-09-16 11:32:57 Re: BUG #15383: Join Filter cost estimation problem in 10.5