ALTER TABLE <name> ADD COLUMN Hangs

--_000_68B59BEDCD36854AADBDF17E91B2937A01A4DC6236EXCHMAILsta ff_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Howdy,

I'm running in an 8.3.3 environment. What could cause, or how can I diagno=
se, why an 'ALTER TABLE <name> ADD COLUMN' statement runs for hours eventua=
lly locking users out and requiring to be killed in the end?

Thanks,

Sam

--_000_68B59BEDCD36854AADBDF17E91B2937A01A4DC6236EXCHMAILsta ff_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>

</style>

</head>

<body lang=3DEN-AU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

Howdy,<o:p></o:p>

<o:p> </o:p>

I’m running in an 8.3.3 environment. What co=
uld
cause, or how can I diagnose, why an ‘ALTER TABLE <name> ADD CO=
LUMN’
statement runs for hours eventually locking users out and requiring to be
killed in the end?<o:p></o:p>

<o:p> </o:p>

Thanks,<o:p></o:p>

<o:p> </o:p>

Sam<o:p></o:p>

</div>

</body>

</html>

--_000_68B59BEDCD36854AADBDF17E91B2937A01A4DC6236EXCHMAILsta ff_--

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 [at] 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

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Wed, Apr 21, 2010 at 8:17 PM, Samuel Stearns
<SStearns [at] internode.com.au> wrote:
> Howdy,
>
> I=92m running in an 8.3.3 environment.=A0 What could cause, or how can I
> diagnose, why an =91ALTER TABLE <name> ADD COLUMN=92 statement runs for h=
ours
> eventually locking users out and requiring to be killed in the end?

By any chance you got a default on there? If so the whole table gets
updated to the default, thus rewritten and locked while this happens.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Wed, Apr 21, 2010 at 8:17 PM, Samuel Stearns
<SStearns [at] internode.com.au> wrote:
> Howdy,
>
> I=92m running in an 8.3.3 environment.=A0 What could cause, or how can I
> diagnose, why an =91ALTER TABLE <name> ADD COLUMN=92 statement runs for h=
ours
> eventually locking users out and requiring to be killed in the end?

And not that it matters here, but is there a reason for running such
out of date pgsql code?

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Thanks Ross and Scott. I got it to complete finally thanks to Ross' tip of=
looking at pg_locks. I had to kill a few processes with exclusive locks o=
n the table and then presto!

Scott, the query didn't have a DEFAULT keyword with it and I've got a reque=
st in with our sysadmins to upgrade us to 8.3.10. Thanks both of you for a=
ll your help.

Sam

-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe [at] gmail.com]
Sent: Thursday, 22 April 2010 4:15 PM
To: Samuel Stearns
Cc: pgsql-admin [at] postgresql.org
Subject: Re: [ADMIN] ALTER TABLE <name> ADD COLUMN Hangs

On Wed, Apr 21, 2010 at 8:17 PM, Samuel Stearns
<SStearns [at] internode.com.au> wrote:
> Howdy,
>
> I'm running in an 8.3.3 environment.=A0 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?

And not that it matters here, but is there a reason for running such
out of date pgsql code?

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

ALTER TABLE <name> ADD COLUMN Hangs

Re: ALTER TABLE <name> ADD COLUMN Hangs

Re: ALTER TABLE <name> ADD COLUMN Hangs

Re: ALTER TABLE <name> ADD COLUMN Hangs

Re: ALTER TABLE <name> ADD COLUMN Hangs