Lock errors produced by PostgreSQL include PID numbers:
UnableToLockRowsToModifyError: Acquiring a lock during commit failed: deadlock detected
DETAIL: Process 30045 waits for ShareLock on transaction 20239679; blocked by process 29982.
Process 29982 waits for ShareLock on transaction 20239915; blocked by process 30028.
Process 30028 waits for AccessExclusiveLock on tuple (366132,30) of relation 16393 of database 16385; blocked by process 30045.
But there's nothing that connects those PID numbers to what the application is doing, so it's harder than necessary to figure out exactly what work (e.g., which HTTP requests) conflicts. We should report the PID of the store connection in the logs so that it's possible to figure this out.
To be useful, this will need to happen for every TPC.
Lock errors produced by PostgreSQL include PID numbers:
But there's nothing that connects those PID numbers to what the application is doing, so it's harder than necessary to figure out exactly what work (e.g., which HTTP requests) conflicts. We should report the PID of the store connection in the logs so that it's possible to figure this out.
To be useful, this will need to happen for every TPC.