[MDEV-25547] Auto-create: Undetected deadlock lasts longer than the configured timeout Created: 2021-04-27 Updated: 2024-01-23 Resolved: 2024-01-23 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Locking, Partitioning, Versioned Tables |
| Affects Version/s: | N/A |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Elena Stepanova | Assignee: | Sergei Golubchik |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
As probably suspected and even expected, concurrent connections can easily deadlock if they come to the point when they need to create a new partition. The deadlock is subject to lock_wait_timeout (which can already be quite high, e.g. the default value is 24 hours), but in fact it takes even more than that – lock waits apparently get serialized and the total duration is up to N x lock_wait_timeout where N is the number of connections participating in concurrency. Below is the test case for 3 connections.
|
| Comments |
| Comment by Aleksey Midenkov [ 2023-10-10 ] |
|
Please review bb-10.9-midenok |
| Comment by Sergei Golubchik [ 2024-01-12 ] |
|
I don't know if that's a bug at all, lock_wait_timeout sets the timeout for one individual lock wait, if there are multiple waits, each one of them can take up to lock_wait_timeout seconds. It's not a total limit for all lock waits together. I'd say this behaves as expected. Also, the commit a4218739d92 fixes a separate problem:
I don't see how this scenario could happen. A creating thread can be blocked for a long time waiting for MDL_EXCLUSIVE, indeed, by another MDL, if a running statement that holds e.g. MDL_SHARED_READ. But in this case new upcoming MDL requests will wait too, there will be no busy loop, instead the an incoming request for e.g. MDL_SHARED_READ will wait for the MDL_EXCLUSIVE, which, in turn, waits for another MDL_SHARED_READ. |