From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
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-23 16:16:38 |
Message-ID: | 18010.1248365798@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-07-23 16:18:39 | Re: Extension Facility |
Previous Message | Andrew Dunstan | 2009-07-23 16:09:07 | Re: Extensions User Design |