Skip site navigation (1) Skip section navigation (2)

Re: Lock Wait Statistics (next commitfest)

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: (view raw, whole thread or download thread mbox)
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

In response to


pgsql-hackers by date

Next:From: David E. WheelerDate: 2009-07-23 16:18:39
Subject: Re: Extension Facility
Previous:From: Andrew DunstanDate: 2009-07-23 16:09:07
Subject: Re: Extensions User Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group