Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 3BBB82E3DB8 for ; Thu, 10 Jan 2008 21:10:05 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 51760-02 for ; Thu, 10 Jan 2008 21:09:45 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4E99C2E3D7A for ; Thu, 10 Jan 2008 21:10:00 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id m0B19wB2020043; Thu, 10 Jan 2008 20:09:58 -0500 (EST) To: Dennis Wang cc: Postgresql Help Subject: Re: URGENET: ALTER statement exectuation hangs when it is executed multiple time on a table In-reply-to: References: Comments: In-reply-to Dennis Wang message dated "Fri, 11 Jan 2008 11:10:07 +1030" Date: Thu, 10 Jan 2008 20:09:58 -0500 Message-ID: <20042.1200013798@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/3 X-Sequence-Number: 6681 Dennis Wang writes: > The actual PostgreSQL commands are: > ALTER TABLE warngrid ALTER COLUMN id SET DEFAULT (nextval('warngrid_seq')* 10)+1; > COPY warngrid FROM 'warngrid.csv' CSV HEADER; > ALTER TABLE warngrid ALTER COLUMN id DROP DEFAULT; > For the first time, these operation execute fine. Then I do these steps: > 4. delete all the records in the table > 5. rerun the shell script to copy records. > Then, the ALTER statement in step 1 hanging there. Did you do all this in one database session, or more than one? If the latter, maybe you haven't committed the transaction that did the DELETE? > I did check the lock state of the warngrid table, it says the process created by the ALTER statement hold an "AccessExclusiveLock" on the table. Did it actually *have* that lock, or was it waiting for it (granted = f in pg_locks)? regards, tom lane