>>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 update on the offending table without issue.
Craig Vosburgh <[EMAIL PROTECTED]> writes:
> As for which process owns that lock, I'm not sure how to find that out
> (sorry newbie). I can find the PID that is waiting for that lock and I can
> find the table/row that appears to be waiting for the lock to perform the
> action but I can't figure o
>
> 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
Craig Vosburgh <[EMAIL PROTECTED]> writes:
> Second, any words of wisdom to help run to ground who's keeping me from
> getting the lock on the 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 thro
Tom,
Yea, about that lock that I *said* I didn't have... We had been joining
through the pg_class and pg_tables tables to get some additional data and it
turns out the row in the pg_locks that shows as locked doesn't have a
relation so it was filtered out due to the join.
So, now that I have acc
Craig Vosburgh <[EMAIL PROTECTED]> writes:
> Got GDB installed on the errant node and did a back trace call (I'm guessing
> that is what you were looking for when you said stack trace) on the process
> that shows in the process table as executing the hung SQL command.
> The backtrace is:
> (gdb)
>> 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 update on the offending table without issue.
Craig Vosburgh <[EMAIL PROTECTED]> 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 update on the offending table wi
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
