Re: pgstat: remove delayed destroy / pipe:

Would someone generate a patch that includes all the new ideas and post
it here? Thanks.

---------------------------------------------------------------------------

Peter Brant wrote:
> 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
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

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