Re: Nonexistent pid in pg_locks
От | Joe Uhl |
---|---|
Тема | Re: Nonexistent pid in pg_locks |
Дата | |
Msg-id | 2E0DB33E-5553-4469-A30A-B2F1EB65B233@gmail.com обсуждение исходный текст |
Ответ на | Re: Nonexistent pid in pg_locks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Nonexistent pid in pg_locks
|
Список | pgsql-bugs |
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote: > Joe Uhl <joeuhl@gmail.com> writes: >> I had to bounce an OpenMQ broker this morning (this database is the >> DB >> for an OpenMQ HA setup) and couldn't get it to reconnect to postgres. >> On inspecting the database I found dozens of vacuum processes waiting >> (I have a cron job that vacuums each night) and chewing up connection >> slots. Killing those left a few autovacuum worker process waiting. >> Killing those left just this one orphaned pid apparently holding a >> lock. Assumably they were all waiting on the lock "held" by 10453. > > What exactly did you do to "kill" those processes? Do you remember > whether any of them happened to have PID 10453? I used "kill pid1 pid2 pid3 ..." (no -9) as root. Unfortunately I do not recall if that pid was one of the processes I killed and not enough scrollback in this screen to see. It is a ShareUpdateExclusiveLock lock though and I definitely only killed vacuum/analyze pids so thinking there is a very high chance of 10453 being one of them. > >> Is there any way for me to clear that orphaned entry out of pg_locks? > > Restarting the database should take care of this, I think. > > regards, tom lane I've got a block of time scheduled for tonight to restart, will give that a shot. Thanks for the response, Joe
В списке pgsql-bugs по дате отправления: