Timeline for Two updates cause a deadlock
Current License: CC BY-SA 3.0
14 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Mar 13, 2018 at 16:00 | answer | added | SAK | timeline score: 1 | |
Sep 12, 2015 at 22:33 | answer | added | Rick James | timeline score: 1 | |
S Sep 11, 2015 at 16:15 | history | suggested | James Lupolt | CC BY-SA 3.0 |
Formatted run-on query so that it is legible and fits in window
|
Sep 11, 2015 at 16:08 | review | Suggested edits | |||
S Sep 11, 2015 at 16:15 | |||||
Sep 11, 2015 at 15:54 | comment | added | maddo7 | With the key I get around 10 times less deadlocks but they still didn't disappear completely, see the edit section of my post. | |
Sep 11, 2015 at 15:53 | history | edited | maddo7 | CC BY-SA 3.0 |
added recent changes
|
Sep 11, 2015 at 12:56 | comment | added | ypercubeᵀᴹ |
And if you add an index on (performed_by, package_sent_diff) ?
|
|
Sep 11, 2015 at 12:39 | comment | added | maddo7 |
I added the AND performed_by = '71602155f18ac6001eb' to the workers, did a few tests and I'm still encountering deadlocks even with that addition.
|
|
Sep 10, 2015 at 21:01 | comment | added | ypercubeᵀᴹ |
Do you still get deadlocks if you add AND performed_by = '71602155f18ac6001eb' to the UPDATE ... WHERE mid = 238323961; ?
|
|
Sep 10, 2015 at 20:58 | comment | added | maddo7 | I updated the code part but I don't use transactions in particular, only the update/select queries | |
Sep 10, 2015 at 20:58 | history | edited | maddo7 | CC BY-SA 3.0 |
added code
|
Sep 10, 2015 at 20:21 | comment | added | ypercubeᵀᴹ | I think it would best if you added the code of all the transactions/procedures you use. | |
Sep 10, 2015 at 19:20 | history | edited | maddo7 | CC BY-SA 3.0 |
added 21 characters in body
|
Sep 10, 2015 at 18:14 | history | asked | maddo7 | CC BY-SA 3.0 |