Well, we are currently passing INFINITE timeout value to WaitForMultipleObjects() API which is hanging. I thought of changing this INIFINTE timeout interval to some finite value like say 1 sec and could not reproduce the issue. But, having said that i checked the older code where this issue does not exists and found here as well we are passing INFINTE timeout value to WaitForMultipleObjects(). So not sure if this passing INFINITE timeout is really an issue. Attached is a small patch that has my changes.
On Thu, Dec 8, 2016 at 1:51 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Dec 07, 2016 at 03:16:09PM +0530, Ashutosh Sharma wrote: > > Problem Analysis: > > ------------------------- > > Allthough i am very new to Windows, i tried debugging the issue and > > could find that Backend is not receiving the query executed after > > "SELECT pldbg_attach_to_port(2)" and is infinitely waiting on > > "WaitEventSetWaitBlock()" at WaitForMultipleObjects() to read the > > input command. Below is the backtrace for the same. > > This code was indeed in need of review. It seems that you are giving > enough information to reproduce the problem. I'll try to dig into > it... > -- > Michael >
diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c index b7e5129..eae2ebb 100644 --- a/src/backend/storage/ipc/latch.c +++ b/src/backend/storage/ipc/latch.c @@ -1395,7 +1395,7 @@ WaitEventSetWaitBlock(WaitEventSet *set, int cur_timeout, * Need to wait for ->nevents + 1, because signal handle is in [0]. */ rc = WaitForMultipleObjects(set->nevents + 1, set->handles, FALSE, - cur_timeout); + 1000); /* Check return code */ if (rc == WAIT_FAILED)
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
