Re: Problem running "ALTER TABLE...", ALTER TABLE waiting
От | Brian McNally |
---|---|
Тема | Re: Problem running "ALTER TABLE...", ALTER TABLE waiting |
Дата | |
Msg-id | 502553B9.1080900@uw.edu обсуждение исходный текст |
Ответ на | Re: Problem running "ALTER TABLE...", ALTER TABLE waiting (Sergey Konoplev <sergey.konoplev@postgresql-consulting.com>) |
Список | pgsql-general |
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 > > >
В списке pgsql-general по дате отправления: