Re: Performance degradation in commit ac1d794

From: Andres Freund <andres(at)anarazel(dot)de>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>,Amit Kapila <amit(dot)kapila(at)huawei(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance degradation in commit ac1d794
Date: 2016-03-19 07:10:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On March 18, 2016 11:52:08 PM PDT, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>On Sat, Mar 19, 2016 at 12:14 PM, Andres Freund <andres(at)anarazel(dot)de>
>> On March 18, 2016 11:32:53 PM PDT, Amit Kapila
>> >On Sat, Mar 19, 2016 at 12:00 AM, Andres Freund <andres(at)anarazel(dot)de>
>> >wrote:
>> >>
>> >> On 2016-03-18 20:14:07 +0530, Amit Kapila wrote:
>> >>
>> >> > I have done some
>> >> > tests on Windows with 0003 patch which includes running the
>> >regressions
>> >> > (vcregress check) and it passes. Will look into it tomorrow
>> >again
>> >and
>> >> > share if I find anything wrong with it, but feel to proceed if
>> >want.
>> >>
>> >> Thanks for the testing thus far! Let's see what the buildfarm has
>> >> say.
>> >>
>> >
>> >Won't the new code needs to ensure that ResetEvent(latchevent)
>> >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
>objects become signaled.
>"When *bWaitAll* is *FALSE*, this function checks the handles in the
>in order starting with index 0, until one of the objects is signaled.
>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? It's be absurdly broken if it handled edge triggered enemy's like FD_CLOSE in a way you can't discover.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2016-03-19 07:29:15 Re: incorrect docs for pgbench / skipped transactions
Previous Message Amit Kapila 2016-03-19 06:52:08 Re: Performance degradation in commit ac1d794