Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id B2AC3633320
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Thu, 22 Apr 2010 00:43:29 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024) with ESMTP id 47607-10 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Thu, 22 Apr 2010 03:43:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from cooker.cnx.rice.edu (cooker.cnx.rice.edu [168.7.5.70])
	by mail.postgresql.org (Postfix) with ESMTP id 133D6632454
	for <pgsql-admin@postgresql.org>; Thu, 22 Apr 2010 00:43:19 -0300 (ADT)
Received: from reedstrm by cooker.cnx.rice.edu with local (Exim 4.63)
	(envelope-from <reedstrm@rice.edu>) id 1O4nJt-0001H6-P2
	for pgsql-admin@postgresql.org; Wed, 21 Apr 2010 22:43:17 -0500
Date: Wed, 21 Apr 2010 22:43:17 -0500
From: "Ross J. Reedstrom" <reedstrm@rice.edu>
To: pgsql-admin@postgresql.org
Subject: Re: ALTER TABLE <name> ADD COLUMN Hangs
Message-ID: <20100422034317.GA3902@rice.edu>
Mail-Followup-To: "Ross J. Reedstrom" <reedstrm>,
	pgsql-admin@postgresql.org
References: 
 <68B59BEDCD36854AADBDF17E91B2937A01A4DC6236@EXCHMAIL.staff.internode.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <68B59BEDCD36854AADBDF17E91B2937A01A4DC6236@EXCHMAIL.staff.internode.com.au>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-0.843 tagged_above=-10 required=5 tests=AWL=-1.633,
	BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201004/298
X-Sequence-Number: 34392

On Thu, Apr 22, 2010 at 11:47:34AM +0930, Samuel Stearns wrote:
> Howdy,
> 
> I'm running in an 8.3.3 environment.  What could cause, or how can I diagnose, why an 'ALTER TABLE <name> ADD COLUMN' statement runs for hours eventually locking users out and requiring to be killed in the end?
> 

ALTER TABLE commands require an exclusive lock on the table. I'm
guessing you've got a long-running transaction ahead of the ALTER TABLE.
take a look at pg_stat_activity, in particular 'waiting' and pg_locks.

Ross
-- 
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
The Connexions Project      http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE