Oh I see. Yeah it’s kind of obvious now that you point it out!
> Btw, do the transactions use explicit locking?
We occasionally use for update so that could be involved. We’ll have a closer
look at the code involved.
I’m still curious about why the locks are both transaction locks rather tha
My guess is that the transaction doing:
update "planscheduleitem" set "planschedule"=$1 where "psi"=$2
updates ticket before reaching that point
And
update ticket set unread = true where ticketid = $1
updates planscheduleitem before that
Does it make sense to you? Btw, do the transactions use
Thanks for your response
> Does any of the two tables have triggers?
Yes the ticket table has a trigger that inserts changes into a ticketstatuslog
table when the ticket.status column changes and on insert.
ticket_status_insert_trigger AFTER INSERT ON ticket FOR EACH ROW EXECUTE
PROCEDURE
Hi. Does any of the two tables have triggers? What's the database /
transaction isolation level? Do the updates run in a transaction among
other read / write operations within the same transaction ?
Regards.
2018-02-18 23:28 GMT-06:00 David Wheeler :
> Hi,
>
> We’re seeing deadlock semi-regularly
Hi,
We’re seeing deadlock semi-regularly (0-2 per day) that I’m really having
trouble getting to the bottom of.
Process 7172 waits for ShareLock on transaction 4078724272; blocked by process
7186.
Process 7186 waits for ShareLock on transaction 4078724210; blocked by process
7172.
The two qu
