Best guess you are running into what is described here: https://www.postgresql.org/docs/9.5/static/explicit-locking.html#LOCKING-DEADLOCKS Both transactions are holding locks on rows in T1 that the other wants also. I may be missing something, but I am not sure why it is necessary to run both sessions concurrently? Could you not do session1 and once it completes then session2?
Sessions are running concurrently because of flexibility - they are two different scheduled jobs launching at different times and performing different set of operations.
Of course I can play with scheduling timings and make them not intersect with each other (which I've done already btw), but that's only a temp solution.
So how in PostgreSQL-world 2 or more transactions can update the same table without deadlocking? I can't believe it's not possible, there must be some sort of synchronization primitive. Does it support a "named mutex" concept from a system-programming world? I bet there is something more suitable.
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
