From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lock Wait Statistics (next commitfest) |
Date: | 2009-07-25 00:22:50 |
Message-ID: | 4A6A505A.5070504@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-07-25 00:24:28 | Re: Proposal: More portable way to support 64bit platforms |
Previous Message | KaiGai Kohei | 2009-07-25 00:16:47 | Re: SE-PostgreSQL Specifications |