Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Possible explanation for Win32 stats regression

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: "korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Possible explanation for Win32 stats regression
Date: 2006-07-29 14:21:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
heh. I was just doing it the way Tom suggested - see attached. With a 
little more trouble we could also keep track if the listened for events 
and sometimes save ourselves a second call to WSAEventSelect, but I'm 
not sure it's worth it.



korryd(at)enterprisedb(dot)com wrote:
>> Is anyone working on this?
>> Tom Lane wrote:
>> > korry <korry(at)appx(dot)com <mailto:korry(at)appx(dot)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).

Attachment: statsfix.patch
Description: text/x-patch (1.0 KB)

In response to


pgsql-hackers by date

Next:From: Tzahi FadidaDate: 2006-07-29 14:24:57
Subject: pgindet ^M
Previous:From: Bruce MomjianDate: 2006-07-29 13:31:31
Subject: Re: On-disk bitmap index patch

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-07-29 15:21:44
Subject: Re: [HACKERS] More #ifdef fun: src/interfaces/libpq/win32.c
Previous:From: korryd@enterprisedb.comDate: 2006-07-29 12:18:33
Subject: Re: [HACKERS] Possible explanation for Win32 stats regression test

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group