Commit ebc2c91
committed
store: Fix deadlock between AcquireHaltLock and processLTXStreamFrame
Moving the halt lock check after receiving the LTX increases the probability of an existing deadlock:
- AcquireHaltLock stores remoteHaltLock and calls WaitPosExact, i.e. it waits for processLTXStreamFrame to
process pending LTXs
- processLTXStreamFrame sees remoteHaltLock != nil (this is more likely now, since it receives the LTX first)
- It incorrectly assumes the remote lock is stale and tries to clear it, since we don't expect new LTXs from
the primary while we hold the halt lock
- UnsetRemoteHaltLock deadlocks in Recover, because processLTXStreamFrame already called AcquireWriteLock
- WaitPosExact deadlocks, because it's waiting for processLTXStreamFrame, which is deadlocked
Instead of trying to clear the remote lock locally, processLTXStreamFrame will perform recovery so the LTX can
be applied. If the remote lock was stale, we'll now only find out when committing a transaction, as the
primary will reject the remote commit. Deferring the error is an acceptable trade-off, as the halt lock is
intended to be short-lived.1 parent 62a68cc commit ebc2c91
1 file changed
Lines changed: 8 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1583 | 1583 | | |
1584 | 1584 | | |
1585 | 1585 | | |
1586 | | - | |
1587 | | - | |
| 1586 | + | |
| 1587 | + | |
| 1588 | + | |
1588 | 1589 | | |
1589 | | - | |
| 1590 | + | |
| 1591 | + | |
1590 | 1592 | | |
1591 | | - | |
1592 | | - | |
1593 | | - | |
| 1593 | + | |
| 1594 | + | |
| 1595 | + | |
1594 | 1596 | | |
1595 | 1597 | | |
1596 | 1598 | | |
| |||
0 commit comments