Three way deadlock update#
Update 3: I needed to update the LOCK_DEBUG_ENABLED inline function to unconditionally return true to see the ShareLock creations.
Three way deadlock how to#
Any suggestions for how to dig into the source of the ShareLock? I see similar results when querying the pg_locks table: always a transaction waiting on a ShareLock of another transaction which is blocking on a tuple from the first transaction. (Format is date program virtualtxid txid msg)īut I don't see where the ShareLock is created, or why transaction 4773 would be blocking on transaction 4774. Process 54157 waits for ExclusiveLock on tuple (1,16) of relation 18150 of database 18136 blocked by process 54131. The updated deadlock message is: Process 54131 waits for ShareLock on transaction 4774 blocked by process 54157. Update #2: I rebuilt Postgres with LOCK_DEBUG and ran with trace_locks=on in an attempt to wrap my head around the order in which locks are taken. I'll look into getting details for the transaction when I can reproduce this I am analyzing the logs after the fact. There is one trigger on the table for updating an updated_at column with current_timestamp(): CREATE OR REPLACE FUNCTION update_timestamp() RETURNS TRIGGER AS $$
There are other commands in this transaction, although I don't believe they are touching the "user" table. Update for Erwin's questions in the comments: This is Postgres 9.3.
Any ideas on how I can solve this, or debug it further? I suspect the RETURNING clause has something to do with it, but I can't see exactly why. I am not updating multiple rows of this table out of order. This doesn't seem like your run-of-the-mill deadlock you see demonstrated in the documentation. The user_id is the same in all three transactions.) Process 5670 waits for ExclusiveLock on tuple (33,12) of relation 31709 of database 16393 blocked by process 5671. Process 5652 waits for ShareLock on transaction 3382643 blocked by process 5670. The log message is, Process 5671 waits for ExclusiveLock on tuple (33,12) of relation 31709 of database 16393 blocked by process 5652. I am hitting a three-way deadlock in Postgres, and I don't really understand what is happening that is causing it.
0 kommentar(er)
