Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 11/10/14, 12:56 PM, Andres Freund wrote:
>> If you want to do this - and I sure don't want to stop you from it - you
>> should look at it from a general perspective, not from the perspective
>> of how skipped cleanup locks are logged.
> Honestly, my desire at this point is just to see if there's actually a problem. Many people are asserting that this
shouldbe a very rare occurrence, but there's no way to know.
> Towards that simple end, I'm a bit torn. My preference would be to simply log, and throw a warning if it's over some
threshold.I believe that would give the best odds of getting feedback from users if this isn't as uncommon as we
think.
> I agree that ideally this would be tracked as another stat, but from that standpoint I think there's other, much more
importantmetrics to track, and AFAIK the only reason we don't have them is that busy systems already push pgstats to
it'slimits. We should try and fix that, but that's a much bigger issue.
Yeah. We know that per-table pgstat counters are a pretty expensive thing
in databases with many tables. We should absolutely not be adding them on
mere speculation that the number might be interesting.
Now, that objection would not apply to a per *database* counter, but I'm
not sure if tracking the numbers at that granularity would help anyone.
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is really an issue.
regards, tom lane
