dan chak wrote:
What would be really great would be to know what the other query is,
as opposed to just the pid (not sure from this output if it's 4483 or
29245). Also not sure if this is the right list for this. But
potentially someone on here may have a good tip on debugging deadlocking?
Just logging the other query would be a nasty information disclosure
problem.
Process blah waits for sharelock on transaction blah blocked by process blah
Context: sql statement "update passwords set password = 'kitty' where
user = 'dummy'"
Blocking sql statement: "update passwords set password = 'woof' where
user 'dummy'"
Ouch.
What could be more securely done, though, would be to issue a NOTICE on
the backend on which the deadlocking transaction not killed is running
that includes the backend pid and the problem statement. Your later log
analysis could then match up the statements from the separate log
records. Including the transaction IDs of both in both log lines would
be nice too, as pids get reused.
Sound sane?
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
