Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id CAA4eK1KuLwbPnx38SRMOpzTX25Xazk8_mLP0WO9o8pnC_FARNQ@mail.gmail.com
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Responses Re: Performance degradation in commit ac1d794
List pgsql-hackers
On Fri, Mar 18, 2016 at 1:34 PM, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2016-03-17 09:01:36 -0400, Robert Haas wrote:
> > 0001: Looking at this again, I'm no longer sure this is a bug.
> > Doesn't your patch just check the same conditions in the opposite
> > order?
>
> Which is important, because what's in what pfds[x] depends on
> wakeEvents. Folded it into a later patch; it's not harmful as long as
> we're only ever testing pfds[0].
>
>
> > 0003: Mostly boring.  But the change to win32_latch.c seems to remove
> > an unrelated check.
>
> Argh.
>

+ * from inside a signal handler in latch_sigusr1_handler().

  *

  * Note: we assume that the kernel calls involved in drainSelfPipe()

  * and SetLatch() will provide adequate synchronization on machines

  * with weak memory ordering, so that we cannot miss seeing is_set if

  * the signal byte is already in the pipe when we drain it.

  */

- drainSelfPipe();

-



Above part of comment looks redundant after this patch.  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 once again and share if I find anything wrong with it, but feel to proceed if you want.


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

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: btree_gin and btree_gist for enums
Next
From: Tom Lane
Date:
Subject: Re: WIP: Upper planner pathification