Matthias Apitz <guru@xxxxxxxxxxx> writes: > One of our clients running our LMS on top of PostgreSQL 13.1 created a > ticket with these messages: > 2023-09-30 16:50:50.951 CEST [18117] ERROR: deadlock detected > 2023-09-30 16:50:50.951 CEST [18117] DETAIL: Process 18117 waits for ShareLock on transaction 150396154; blocked by process 18187. > Process 18187 waits for ShareLock on transaction 150396155; blocked by process 18117. > Process 18117: fetch hc_d03geb > Process 18187: fetch hc_d02ben > 2023-09-30 16:50:50.951 CEST [18117] HINT: See server log for query details. > 2023-09-30 16:50:50.951 CEST [18117] CONTEXT: while locking tuple (38,57) in relation "d03geb" > 2023-09-30 16:50:50.951 CEST [18117] STATEMENT: fetch hc_d03geb > The shown PIDs for sure are the ones of the Pos backend proc (on Linux). > Is there any chance to investigate it further? Well, not with this amount of info. But it seems like a fairly safe bet that the locks being contended for arise from trying to SELECT-FOR-UPDATE the same two rows in different orders. You'd need to look at the cursors being fetched from and see what you can do to make their row locking orders be reliably consistent. Or see if you can avoid needing exclusive row locks in the first place. regards, tom lane
