Re: Nonexistent pid in pg_locks
От | Joe Uhl |
---|---|
Тема | Re: Nonexistent pid in pg_locks |
Дата | |
Msg-id | AC9D203B-E956-47A8-802E-AE7793C78A6B@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 3:00 PM, Tom Lane wrote: > Joe Uhl <joeuhl@gmail.com> writes: >> On Jul 8, 2009, at 2:41 PM, Tom Lane wrote: >>> 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. > > Hmm. In any case that shouldn't have led to a lock left hanging. > Assuming that it was a regular and not autovacuum, do you know what > the exact command would have been? (In particular, FULL, ANALYZE, > etc options) > > regards, tom lane They were VACUUM VERBOSE ANALYZE. Specifically run with "/usr/bin/ vacuumdb -v --analyze $DB_NAME" in the cron job each night.
В списке pgsql-bugs по дате отправления: