Fix race condition that lead to WALInsertLock deadlock with commit_delay.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Sun, 2 Aug 2015 17:08:10 +0000 (20:08 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Sun, 2 Aug 2015 17:09:05 +0000 (20:09 +0300)
commitbab959906911c97437f410a03b0346e6dd28d528
tree24fcd8c55bc1ca538994c1e7a23ce09a3fe1c637
parente39a3b2efee07237ee34572472edf8a07dbb9e2f
Fix race condition that lead to WALInsertLock deadlock with commit_delay.

If a call to WaitForXLogInsertionsToFinish() returned a value in the middle
of a page, and another backend then started to insert a record to the same
page, and then you called WaitXLogInsertionsToFinish() again, the second
call might return a smaller value than the first call. The problem was in
GetXLogBuffer(), which always updated the insertingAt value to the
beginning of the requested page, not the actual requested location. Because
of that, the second call might return a xlog pointer to the beginning of
the page, while the first one returned a later position on the same page.
XLogFlush() performs two calls to WaitXLogInsertionsToFinish() in
succession, and holds WALWriteLock on the second call, which can deadlock
if the second call to WaitXLogInsertionsToFinish() blocks.

Reported by Spiros Ioannou. Backpatch to 9.4, where the more scalable
WALInsertLock mechanism, and this bug, was introduced.
src/backend/access/transam/xlog.c