From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com> |
Subject: | Re: Stats collection on Windows |
Date: | 2006-04-05 14:54:09 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA35258@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Search for "is known to be dead, ignoring" to find the
> re-used process
> > IDs. Things start out clean, but after a few cycles
> anywhere between
> > 1 and 5 backends are being missed.
>
> Looking at the pgstats code, I notice that once it makes an
> entry in the dead-backends hashtable, it keeps that entry
> (rejecting any messages with the same PID) for 10 seconds.
> That seems like approximately forever on modern machines,
> certainly much more than any plausible out-of-order condition
> in the UDP packet stream. It could easily be enough to get
> us in trouble on Unix machines, never mind Windows.
>
> A conservative suggestion would be to trim down the destroy interval.
> A more radical one is to question whether we need the destroy
> delay mechanism at all. What if we got rid of all that logic
> and simply let the collector delete stuff when it's told to?
> Out-of-order messages could cause entries to be re-created
> after they've been deleted, but I'm not sure that I see any
> harm in that. Bogus DB and table entries are already ignored
> in the pgstats views (because they won't join to anything in
> the system catalogs) and we also have a filter for bogus
> backend entries. There are also mechanisms that ensure these
> entries will go away eventually: pgstat_vacuum_tabstat for DB
> and table entries, and eventual re-use of a BackendId slot
> for backends.
> So I'm sort of thinking that the destroy delay has outlived
> its usefulness.
After reviewing my own patch I just sent in (stats write delay), I
realised I had just upped that from 10 seconds to 5 minutes. Which is
then even longer than forever :)
Which prompted me to consider suggesting just this - do we really need
the destroy functionality. From what I could tell it did look reasonable
to get rid of it for these reasons.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-05 15:06:49 | Re: Stats collection on Windows |
Previous Message | patrick | 2006-04-05 14:50:28 | recover without $PGDATA/global |