Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C79FD1337BC4 for ; Fri, 12 Nov 2010 11:51:14 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 47156-07 for ; Fri, 12 Nov 2010 15:51:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-px0-f174.google.com (mail-px0-f174.google.com [209.85.212.174]) by mail.postgresql.org (Postfix) with ESMTP id C496C1337B9E for ; Fri, 12 Nov 2010 11:51:03 -0400 (AST) Received: by pxi15 with SMTP id 15so611591pxi.19 for ; Fri, 12 Nov 2010 07:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:cc :subject:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=p82ZPFxFEtPQ+oyb/ZzRjVUbUwITfumApU7g11X0Rb0=; b=DM7B3HK8JcG4lsbbGerbzB4dEr9i9TXLaqKvN8A1jywaZh6yvFUm9uFJfkCnBJbDEw Rsm7HepDniH39IXwjSWhhz/2LJp9KxtveHDJXWD9IRgSZHYwmYd0017dQKYmS1Y6UaQl 14Kinu3kD7gDpnmnE3kuMgHxDtuqKknCIPyWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:cc:subject:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=sapyiHMT7/BAZNUCVWqoRA5LiSxC7dTEFJwLFNQi6TpHm2AIqIaP1lXBvn1FPSwY35 xd94Fmx974gFvaul2Mhm9nXsf6artlpmipu50sJTpaEB+dHsETl7lRgQnUcVsaBN1UKM 2bDgBjkAqtElz9G4t8zn+nx+n3BRUVSJukBGk= Received: by 10.142.165.18 with SMTP id n18mr1972950wfe.175.1289577063975; Fri, 12 Nov 2010 07:51:03 -0800 (PST) Received: from eddie (c-67-186-249-122.hsd1.ut.comcast.net [67.186.249.122]) by mx.google.com with ESMTPS id p8sm4039650wff.4.2010.11.12.07.51.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 07:51:02 -0800 (PST) Message-ID: <4cdd6266.08c08e0a.59ee.ffffe39b@mx.google.com> Date: Fri, 12 Nov 2010 08:50:41 -0700 From: Joshua Tolley To: Bryce Nesbitt Cc: pgsql-sql@postgresql.org Subject: Re: "slow lock" log in addition to log_min_duration_statement ? References: <4CDB007E.7010904@obviously.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <4CDB007E.7010904@obviously.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201011/19 X-Sequence-Number: 34757 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 10, 2010 at 12:28:46PM -0800, Bryce Nesbitt wrote: > I have a cluster with log_min_duration_statement set to log slow =20 > queries. Presently what I'm tracking down is almost certainly a lock =20 > problem. Is there any analog of log_min_duration_statement for locks? = =20 > If there is a lock on a certain critical tables for more than a few =20 > hundredths of a second I want to know. You could try log_lock_waits: http://www.postgresql.org/docs/8.3/interactive/runtime-config-logging.html#= GUC-LOG-LOCK-WAITS It's defined in terms of deadlock_timeout, and reducing that to "a few hundredths of a second" like you're interested in might cause all kinds of load from the deadlock detector. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzdYlEACgkQRiRfCGf1UMOdGwCgr9nmq3OlWjFFyiem5TkRM5oH CrIAn3g9SpF0kBjv7rH+kMDLxkPMB4c8 =OipI -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--