Re: Proposal: Log inability to lock pages during vacuum
От | Tom Lane |
---|---|
Тема | Re: Proposal: Log inability to lock pages during vacuum |
Дата | |
Msg-id | 28996.1415670779@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: Log inability to lock pages during vacuum (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Proposal: Log inability to lock pages during vacuum
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: