Craig Vosburgh craig(dot)vosburgh(at)cassatt(dot)com 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
Craig Vosburgh craig(dot)vosburgh(at)cassatt(dot)com 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
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) bt
#0
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
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 through
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 that is
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 out
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
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 without
