On Fri, Dec 9, 2016 at 4:11 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier > <michael.paqu...@gmail.com> 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 has not set WL_LATCH_SET and the latch is set, then the wait >> will stop. > > Nah. I misread the code. set->latch is not NULL only if WL_LATCH_SET is > enabled.
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, but what I think is not fine is the fact that this WSA event is *not* reset even once in-between when calling WaitEventAdjustWin32() to adjust an event HANDLE to wait for, and the FeBeWaitEvent is used a lot. That's one inconsistency with the old code that always closed the WSA event after using it, unconditionally. Now that we cache it I think that we had better put it in a clean state every time we want to use it again. With the pointer miscalculation I pointed out upthread it gives the patch attached. Ashutosh, could you try it and see if it improves things? -- Michael
fix-wait-event-win32.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
