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 по дате отправления: