Re: Possible explanation for Win32 stats regression test - Mailing list pgsql-hackers

From korryd@enterprisedb.com
Subject Re: Possible explanation for Win32 stats regression test
Date
Msg-id 1154175513.7099.51.camel@sakai.localdomain
Whole thread Raw
In response to Re: Possible explanation for Win32 stats regression test  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [PATCHES] Possible explanation for Win32 stats regression  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Is anyone working on this?

Tom Lane wrote:
> korry <korry@appx.com> writes:
> > The problem is that, each time you go through
> > pgwin32_waitforsinglesocket(), you tie the *same* kernel object
> > (waitevent is static) to each socket.
> 
> > The fix is pretty simple - just call WSAEventSelect( s, waitevent, 0 )
> > after WaitForMultipleObjectsEx() returns.  That disassociates the socket
> > from the Event (it will get re-associated the next time
> > pgwin32_waitforsingleselect() is called.  
> 
> Hmm.  Presumably we don't do this a whole lot (use multiple sockets) or
> we'd have noticed before.  Perhaps better would be to keep an additional
> static variable saying which socket the event is currently associated
> to, and only issue the extra WSAEventSelect calls if we need to change
> it.  Or is WSAEventSelect fast enough that it doesn't matter?
> 

Here's a simple patch that fixes the problem (I haven't explored the performance of this patch compared to Tom's suggestion).

        -- Korry

pgsql-hackers by date:

Previous
From: Tzahi Fadida
Date:
Subject: Re: Formulating an sql query with CTID
Next
From: Bruce Momjian
Date:
Subject: Re: On-disk bitmap index patch