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