Re: pgstat: remove delayed destroy / pipe:

Sounds good. I'll check how much we're actually looping too.

Pete

>>> "Magnus Hagander" <mha(at)sollentuna(dot)net> 04/06/06 10:27 pm >>>
That's probably not a bad idea. AFAIK we haven't had reports of it
elsewhere, but it oculd happen. Want to code up a new patch, and run
some tests?

//Magnus

> -----Original Message-----
>
> 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" <mha(at)sollentuna(dot)net> 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 majordomo(at)postgresql(dot)org so that
> your
> message can get through to the mailing list cleanly
>