Re: Proposal: Log inability to lock pages during vacuum
От | Jim Nasby |
---|---|
Тема | Re: Proposal: Log inability to lock pages during vacuum |
Дата | |
Msg-id | 547CB9AF.6060703@BlueTreble.com обсуждение исходный текст |
Ответ на | 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 |
On 12/1/14, 11:57 AM, Andres Freund wrote: > On 2014-11-30 20:46:51 -0600, Jim Nasby wrote: >> On 11/10/14, 7:52 PM, Tom Lane wrote: >>> 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. >> >> Attached is a patch that does this. > > Unless somebody protests I plan to push this soon. I'll change two > things: > > * Always use the same message, independent of scan_all. For one Jim's > version would be untranslatable, for another it's not actually > correct. In most cases we'll *not* wait, even if scan_all is > true as we'll often just balk after !lazy_check_needs_freeze(). Good point. > * Change the new bit in the errdetail. "could not acquire cleanup lock" > sounds too much like an error to me. "skipped %u pinned pages" maybe? Seems reasonable. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: