Separate WAL page idx lock from page lock in BMFileHandle #1398
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces
WALPageIdxGroup
in BMFileHandle, the WALPageIdxGroup keeps a set of WAL page indexes for a page group with updated pages in WAL file.This also changes how BMFileHandle stores wal page indexes, switching from vector-based to map-based. We assume each write transaction will only touch a small number of page groups, so map-based method can be efficient.
After the change, we can now remove two interfaces,
pinWithoutAcquiringPageLock
andunpinWithoutAcquiringPageLock
, in BufferManager. PageLock is only used specifically by BufferManager to correctly manage pages and frames.Any operations that require sync on accessing wal page idx of an original page should acquire the WAL page idx lock.
Additionally, this PR fixes a potential bug in
BMFileHandle::clearWALPageIdxIfNecessary
.There was a missing lock acquire (only
releasePageLock(pageIdx);
was called) in the function, but adding lock acquiring logic can lead to dead locks in the testSetNodeStructuredPropTransactionTest::SetVeryLongStringErrorsTest
.The reason is writing long string overflow triggers exception thrown, which didn't correctly release locks.
See changes in
StringPropertyColumn::writeValueForSingleNodeIDPosition
.The change is also propagated to
ListPropertyColumn::writeValueForSingleNodeIDPosition
though it has nothing to do with the failing test.