title: postmortem deadlock debugging in PostgreSQL
body: <p>I want to collect post-mortem debugging information about both the "winner" transaction and the "loser" transaction(s) in a PostgreSQL deadlock.</p>
  
  <ul>
  <li>I found <a href="https://wiki.postgresql.org/wiki/Lock_Monitoring" rel="noreferrer">this</a> wiki page which includes some good live views that would give hints about what is <em>currently</em> going wrong, but if I understand correctly, by the time the losing transaction is already being rolled back most of the most useful information will already have been removed from these live views.</li>
  <li>I saw options such as <a href="http://www.postgresql.org/docs/current/static/runtime-config-locks.html#GUC-DEADLOCK-TIMEOUT" rel="noreferrer">deadlock_timeout</a> and <a href="http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-LOG-LOCK-WAITS" rel="noreferrer">log_lock_waits</a> which log information about the losing transaction, but notably not the winning transaction. There doesn't appear to be any way to customize the log output produced to include more detailed information than this (notably, none of these integers mean anything when I'm debugging based on logs after the fact):
  <code>
  LOG:  process 11367 still waiting for ShareLock on transaction 717 after 1000.108 ms
  DETAIL:  Process holding the lock: 11366. Wait queue: 11367.
  CONTEXT:  while updating tuple (0,2) in relation "foo"
  STATEMENT:  UPDATE foo SET value = 3;
  </code></li>
  </ul>
  
  <p>Is there a better data source I can use to collect this information?</p>