>>Craig Vosburgh writes:
>> We've dumped the locks and it shows that all locks have been granted so
>> it appears that it is not a lock that is standing in our way. We've
>> also gone in via psql while the update is hung and were able to perform
>> an upd
>
> What's the locktype?
>
Yep, locktype is transaction.
> If (as I suspect) it's a transaction or
> virtualtransaction lock, then which process holds that lock and what's
> it doing?
As for which process owns that lock, I'm not sure how to find that out
(sorry newbie). I can find the PID th
offending row? The row in the lock table that shows
granted false does not show as belonging to a database or relation (both
null) so I can't join through to get the table info from pg_table.
Thanks for all the help,
-Craig
On 5/12/08 12:16 PM, "Tom Lane" <[EMAIL PROTECTED]
>> Craig Vosburgh writes:
>> We've dumped the locks and it shows that all locks have been granted so
>> it appears that it is not a lock that is standing in our way. We've
>> also gone in via psql while the update is hung and were able to perform
>> an upd
All,
I'm hoping for some help on trying to figure out what is going on with
our postgres implementation. We have an application that uses Hibernate
to persist objects into a Postgres database. We've run into a
semi-repeatable problem (every other or every third test run) where we
issue an update
