In an interesting twist, we tried to drop the table in question and got
this:
-bash-3.2$ dropdb exomeSNP
dropdb: database removal failed: ERROR: database "exomeSNP" is being
accessed by other users
DETAIL: There are 1 prepared transaction(s) using the database.
-bash-3.2$
So, it seems that maybe there is prepared transaction that could be
holding up the ALTER TABLE. I'm a bit confused though since previous
attempts to find that didn't succeed. Maybe I just haven't used to
correct query yet.
--
Brian McNally
On 08/09/2012 12:30 AM, Sergey Konoplev wrote:
On Thu, Aug 9, 2012 at 4:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Brian McNally <bmcna...@uw.edu> writes:
Ok, I'm running with all available updates and kernel 2.6.18-308.4.1.el5
but am still having the same problem.
It's fairly clearly blocked on a lock ... have you looked into the
pg_locks view to see what is holding the lock?
There is a hidden part of the conversation. We have already checked
pg_locks and no locks were there. Moreover there were no other
activity except the ALTER. And this was the odd part.
(I'm wondering about a prepared transaction, myself. There isn't much
else that could hold a lock across a server restart.)
Are not they shown by pg_locks?
regards, tom lane
-
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
