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.


>>> "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
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?


---------------------------(end of
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that
       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

Reply via email to