Re: Lock Wait Statistics (next commitfest)

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: Lock Wait Statistics (next commitfest)
Дата
Msg-id 4A6A505A.5070504@paradise.net.nz
обсуждение исходный текст
Ответ на Re: Lock Wait Statistics (next commitfest)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> writes:
>   
>> Yeah, enabling log_lock_waits is certainly another approach, however you 
>> currently miss out on those that are < deadlock_timeout - and 
>> potentially they could be the source of your problem (i.e millions of 
>> waits all < deadlock_timeout but taken together rather significant). 
>> This shortcoming could be overcome by making the cutoff wait time 
>> decoupled from deadlock_timeout (e.g a new parameter 
>> log_min_lock_wait_time or similar).
>>     
>
> The reason that they're tied together is to keep from creating
> unreasonable complexity (and an unreasonable number of extra kernel
> calls) in management of the timeout timers.  You will find that you
> can't just wave your hand and decree that they are now decoupled.
>
>   

Thanks Tom - I did wonder if there was a deeper reason they were tied 
together!

Cheers

Mark


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

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: SE-PostgreSQL Specifications
Следующее
От: Dave Page
Дата:
Сообщение: Re: Proposal: More portable way to support 64bit platforms