Re: Performance degradation in commit ac1d794

On Sat, Mar 19, 2016 at 12:40 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On March 18, 2016 11:52:08 PM PDT, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >> >Won't the new code needs to ensure that ResetEvent(latchevent)
> >should
> >> >get
> >> >called in case WaitForMultipleObjects() comes out when both
> >> >pgwin32_signal_event and latchevent are signalled at the same time?
> >>
> >> WaitForMultiple only reports the readiness of on event at a time, no?
> >>
> >
> >I don't think so, please read link [1] with a focus on below paragraph
> >which states how it reports the readiness or signaled state when
> >multiple
> >objects become signaled.
> >
> >"When *bWaitAll* is *FALSE*, this function checks the handles in the
> >array
> >in order starting with index 0, until one of the objects is signaled.
> >If
> >multiple objects become signaled, the function returns the index of the
> >first handle in the array whose object was signaled."
>
> I think that's OK. We'll just get the next event the next time we call
waitfor*. It's also not different to the way the routine is currently
handling normal socket and postmaster events, no?
>

I think the primary difference with socket and postmaster event as compare
to latch event is that it won't allow to start waiting with the waitevent
in signalled state. For socket event, it will close the event in the end
and create again before entring the wait loop in WaitLatchOrSocket. I
could not see any major problem apart from may be spurious wake ups in few
cases (as we haven't reset the event to non signalled state for latch event
before entering wait, so it can just return immediately) even if we don't
Reset the latch event.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com