Re: Proposal: Log inability to lock pages during vacuum

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Proposal: Log inability to lock pages during vacuum
Дата
Msg-id 5460FE0F.20402@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Proposal: Log inability to lock pages during vacuum  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 11/10/14, 11:28 AM, Alvaro Herrera wrote:
> Jim Nasby wrote:
>> On 11/7/14, 8:21 PM, Robert Haas wrote:
>>> On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>>> The problem right now is there's no way to actually obtain evidence that
>>>> this is (or isn't) something to worry about, because we just silently skip
>>>> pages. If we had any kind of tracking on this we could stop guessing. :(
>>>
>>> I could see logging it, but I agree with Andres and Alvaro that the
>>> odds are strongly against there being any actual problem here.
>>
>> I'm fine with that. Any other objections? Andres?
>
> If what we want is to quantify the extent of the issue, would it be more
> convenient to save counters to pgstat?  Vacuum already sends pgstat
> messages, so there's no additional traffic there.

IMHO that would be ideal, but I think Tom was leery of using more space for every table. If we go this route, I'm
guessingwe should only log pages we skip, and not log pages we had to wait for the lock on (in the case of a freeze).
Also,should we still eroprt this even if we are putting it in stats?
 

Is there a way to avoid duplicating the entire eroprt call? I see I could call errstart & friends manually, but
currentlythat's only done in elog.c.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Teaching pg_dump to use NOT VALID constraints
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Allow signal handlers to optionally use SA_SIGINFO information?