On Jul 8, 2009, at 3:42 PM, Tom Lane wrote:
Joe Uhl writes:
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
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, FU
Joe Uhl writes:
> On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
>> 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)
> They we
On Jul 8, 2009, at 3:00 PM, Tom Lane wrote:
Joe Uhl 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
Joe Uhl 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
On Jul 8, 2009, at 2:41 PM, Tom Lane wrote:
Joe Uhl 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 th
Joe Uhl 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
I have a 8.3.6 postgres database running on Arch Linux (2.6.28 kernel)
with the following entry in pg_locks:
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction |
pid | mode | granted
relation
