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 <tgl@sss.pgh.pa.us> wrote:
>> Brian McNally <bmcnally@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
>
>
>