Also, do we want to move the retry loop to pgwin32_recv? That seems like a good idea. I'm not sure users of recv should ever have to deal with WSAEWOULDBLOCK as it's not really an error.
Pete >>> "Magnus Hagander" <[EMAIL PROTECTED]> 04/06/06 9:58 pm >>> > > Attached are two patches which in combination make pg_stat_activity > > work reliably for us on Windows. > > ... > > pgstat.patch removes the delayed destroy code for backends, > databases, > > and tables. Database and table entries are cleaned up immediately > > upon receipt of the appropriate message. > > I'll go ahead and apply the delayed-destroy-removal part > (just to HEAD for the time being --- seems a bit risky to > apply it to the stable branches). The Windows-specific > change sounds like it may need more review. Actually, I think that's mostly me being confused and taking others with me ;-) It's definitly a problem, and we have a solution there. The one thing I'm still a bit concerned about is: Do we need a CHECK_FOR_INTERRUPTS, and do we need an upper limit on the spinning. In theory we can spin with 100% CPU usage, which is not good. So we should either spin a limited amount of times, or we should perhaps introduce a tiny delay? //Magnus ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match