>>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
