Re: Lock Wait Statistics (next commitfest) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lock Wait Statistics (next commitfest)
Date
Msg-id 18010.1248365798@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lock Wait Statistics (next commitfest)  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: Lock Wait Statistics (next commitfest)  (Mark Kirkwood <markir@paradise.net.nz>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Extensions User Design
Next
From: "David E. Wheeler"
Date:
Subject: Re: Extension Facility