Re: Added columns to pg_stat_activity

Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> I'd vote against that.  The mechanism is lossy by design

> Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
> delivery, I wonder what kind of extreme circumstances would need to
> exist for you to lose UDP packets outright over the loopback interface.

If the stats collector gets sufficiently backed up, you will lose
messages.  The most obvious case is the "statistics buffer is full"
error in pgstat_recvbuffer() (and you can find two or three reports
of that message in just the last week or so of the mailing list
archives).  But the entire messaging mechanism is *specifically*
designed to drop messages rather than block backends if the stats buffer
process gets backed up to the point where it can't accept messages fast
enough.  For starters, we'd have used TCP not UDP if we didn't want it
to do that.

>> I don't think it's acceptable to refuse to display information
>> we do have (queries, access counts) just because we don't have every
>> element of a rather-arbitrarily-chosen view row.

> Is there really any point in returning such incomplete statistics data?

Absolutely.  Given the lossiness of the mechanism, the total stats data
is incomplete by definition, and so if we were insistent on returning
only 100% guaranteed data, we might as well shut down the collector and
return nothing.  The entire facility is designed on the assumption that
partial data is better than no data (and also better than taking the
performance hit that would ensue if we tried to guarantee full data).
Please do not try to make piecemeal changes in that basic design
decision.

>> Looking at the code, backendid seems sufficient since that is the
>> lookup key.

> Not if you want to distinguish between dead and live backends, it's not
> (see pgstat_add_backend).

Ah, good point.  But still we need not send more than backend PID plus
BackendId.  (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every message reception in
the stats collector, instead of just indexing into a BackendId array,
so it'd probably be a net loss.)

            regards, tom lane