Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On 2016-12-16 23:04:13 -0500, Robert Haas wrote: > >> BTW, I suggest this rewritten comment: > >> > >> /*-- > >> * FD_READ events are edge-triggered on Windows per > >> * > >>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 21, 2016 at 9:34 PM, Amit Kapila wrote: > On Wed, Dec 21, 2016 at 9:46 PM, Robert Haas wrote: >> On Tue, Dec 20, 2016 at 11:32 PM, Amit Kapila >> wrote: >>> Ashutosh Sharma has helped to test that pldebugger

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 21, 2016 at 9:46 PM, Robert Haas wrote: > On Tue, Dec 20, 2016 at 11:32 PM, Amit Kapila wrote: >> Ashutosh Sharma has helped to test that pldebugger issue is fixed with >> attached version. > > Committed. > Thanks! > Patch by Amit

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Tue, Dec 20, 2016 at 11:32 PM, Amit Kapila wrote: > Ashutosh Sharma has helped to test that pldebugger issue is fixed with > attached version. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Tue, Dec 20, 2016 at 8:04 PM, Robert Haas wrote: > On Sat, Dec 17, 2016 at 5:46 AM, Amit Kapila wrote: >> Yeah, but we are planning to add a generic flag in WaitEvent structure >> which can be used for similar purpose. However, as per your >>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Sat, Dec 17, 2016 at 5:46 AM, Amit Kapila wrote: > Yeah, but we are planning to add a generic flag in WaitEvent structure > which can be used for similar purpose. However, as per your > suggestion, I have changed it only for Win32 port. Also, I kept the > change in

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

> It is fine as per current usage of WaitEventSet API's, however, > Robert's point is valid that user is not obliged to call > ModifyWaitEvent before WaitEventSetWait. Imagine a case where some > new user of this API is calling WaitEventSetWait repeatedly without > calling ModifyWaitEvent. Oops!

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Sat, Dec 17, 2016 at 3:53 PM, Ashutosh Sharma wrote: > Hi, > >>> I think it should be the responsibility of >>> WaitEventSetWaitBlock() to reset the event, if needed, before calling >>> WaitForMultipleObjects(). >>> >> >> If we want to change WaitEventSetWaitBlock then

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Sat, Dec 17, 2016 at 9:34 AM, Robert Haas wrote: > On Fri, Dec 16, 2016 at 10:34 PM, Amit Kapila wrote: >>> I think it should be the responsibility of >>> WaitEventSetWaitBlock() to reset the event, if needed, before calling >>>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi, >> I think it should be the responsibility of >> WaitEventSetWaitBlock() to reset the event, if needed, before calling >> WaitForMultipleObjects(). >> > > If we want to change WaitEventSetWaitBlock then ideally we need to > change all other wait API's (WAIT_USE_SELECT, WAIT_USE_POLL, etc.)

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 16, 2016 at 10:34 PM, Amit Kapila wrote: >> I think it should be the responsibility of >> WaitEventSetWaitBlock() to reset the event, if needed, before calling >> WaitForMultipleObjects(). >> > > If we want to change WaitEventSetWaitBlock then ideally we need

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 16, 2016 at 9:03 PM, Robert Haas wrote: > On Thu, Dec 15, 2016 at 4:17 AM, Amit Kapila wrote: >> On Thu, Dec 15, 2016 at 10:04 AM, Andres Freund wrote: >>> Hi, >>> >>> On 2016-12-12 16:46:38 +0900, Michael Paquier

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 4:17 AM, Amit Kapila wrote: > On Thu, Dec 15, 2016 at 10:04 AM, Andres Freund wrote: >> Hi, >> >> On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: >>> Ashutosh, could you try it and see if it improves things? >> >> So

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 10:04 AM, Andres Freund wrote: > Hi, > > On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: >> Ashutosh, could you try it and see if it improves things? > > So what's the theory of why this triggers pldebugger hangs, but > apparently causes not many

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi, On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: > Ashutosh, could you try it and see if it improves things? So what's the theory of why this triggers pldebugger hangs, but apparently causes not many other problems? I tried to skim pldebugger code, but it's state isn't very condusive to

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Tue, Dec 13, 2016 at 11:19 AM, Andres Freund wrote: > On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: >> OK, I think that I have spotted an issue after additional read of the >> code. When a WSA event is used for read/write activity on a socket, >> the same WSA event

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 7:48 AM, Michael Paquier wrote: > On Thu, Dec 15, 2016 at 1:18 AM, Robert Haas wrote: >> On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma >> wrote: I have just read the patch, and hardcoding

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Thu, Dec 15, 2016 at 1:18 AM, Robert Haas wrote: > On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma > wrote: >>> I have just read the patch, and hardcoding the array position for a >>> socket event to 0 assumes that the socket event will be

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 5:35 AM, Ashutosh Sharma wrote: >> I have just read the patch, and hardcoding the array position for a >> socket event to 0 assumes that the socket event will be *always* the >> first one in the list. but that cannot be true all the time, any code >>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 2:34 AM, Ashutosh Sharma wrote: >> Okay, but I think we need to re-enable the existing event handle for >> required event (FD_READ) by using WSAEventSelect() to make it work >> sanely. We have tried something on those lines and it resolved the >>

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi Micheal,, > I have just read the patch, and hardcoding the array position for a > socket event to 0 assumes that the socket event will be *always* the > first one in the list. but that cannot be true all the time, any code > that does not register the socket event as the first one in the list

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 5:38 PM, Ashutosh Sharma wrote: >> What I think you want to do is modify the flag events associated to >> the socket read/write event to be updated in WaitEventAdjustWin32(), > > Well, this does not work as the following if check does not allow the >

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi Micheal, > I bet that this patch breaks many things for any non-WIN32 platform. It seems to me like you have already identified some issues when testing. If yes, could please share it. I have tested my patch on CentOS-7 and Windows-7 machines and have found no issues. I ran all the

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 4:34 PM, Ashutosh Sharma wrote: > Attached is the patch based on Amit's explanation above. Please have a > look and let me know for any concerns. Thank you Micheal and Andres > for sharing your thoughts and Amit for your valuable inputs. } +

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi, > Okay, but I think we need to re-enable the existing event handle for > required event (FD_READ) by using WSAEventSelect() to make it work > sanely. We have tried something on those lines and it resolved the > problem. Ashutosh will post a patch on those lines later today. Let > us know

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Tue, Dec 13, 2016 at 9:49 PM, Andres Freund wrote: > On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: >> OK, I think that I have spotted an issue after additional read of the >> code. When a WSA event is used for read/write activity on a socket, >> the same WSA event

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 14, 2016 at 1:14 AM, Ashutosh Sharma wrote: > I have been working on this issue for last few days and it seems like > i have almost found the reason for this failure. My findings till date > are as follows. > > Just to confirm if the problem is happening due to

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On 2016-12-12 16:46:38 +0900, Michael Paquier wrote: > OK, I think that I have spotted an issue after additional read of the > code. When a WSA event is used for read/write activity on a socket, > the same WSA event gets reused again and again. That's fine for > performance reasons It's actually

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi All, I have been working on this issue for last few days and it seems like i have almost found the reason for this failure. My findings till date are as follows. Just to confirm if the problem is happening due to reusability of WaitEventSet structure, I had replaced a function call

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Hi Micheal, > Ashutosh, could you try it and see if it improves things? > - > Thanks for your patch. I would like to inform you that I didn't find any improvement with your patch. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 4:11 PM, Michael Paquier wrote: > On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier > wrote: >> This basically means that if the latch is set, we don't wait at all >> and drop the ball. I am wondering: isn't that a

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier wrote: > This basically means that if the latch is set, we don't wait at all > and drop the ball. I am wondering: isn't that a problem even if > WL_LATCH_SET is *not* set? If I read this code correctly, even if > caller

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 2:38 AM, Ashutosh Sharma wrote: > 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 >

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

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

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

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