Re: Nonexistent pid in pg_locks - Mailing list pgsql-bugs

From Joe Uhl
Subject Re: Nonexistent pid in pg_locks
Date
Msg-id AC9D203B-E956-47A8-802E-AE7793C78A6B@gmail.com
Whole thread Raw
In response to Re: Nonexistent pid in pg_locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Nonexistent pid in pg_locks  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Nonexistent pid in pg_locks
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #4907: stored procedures and changed tables