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

Re: Possible explanation for Win32 stats regression test

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: korryd(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible explanation for Win32 stats regression test
Date: 2006-07-29 02:54:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Is anyone working on this?


Tom Lane wrote:
> korry <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?
> Anyway, someone with a Windows machine needs to code and test this ...
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

  Bruce Momjian   bruce(at)momjian(dot)us

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: markDate: 2006-07-29 04:26:23
Subject: Re: On-disk bitmap index patch
Previous:From: Tom LaneDate: 2006-07-29 02:50:01
Subject: Re: [Pgbuildfarm-members] [Fwd: RE: Build farm on Windows]

pgsql-patches by date

Next:From: Joe ConwayDate: 2006-07-29 06:50:05
Subject: Re: [HACKERS] 8.2 features?
Previous:From: Bruce MomjianDate: 2006-07-29 02:26:08
Subject: Re: [HACKERS] pg_regress breaks on msys

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