[SERVER-35569] reIndex should take a Global exclusive lock instead of just Database Created: 12/Jun/18  Updated: 29/Oct/23  Resolved: 13/Jun/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.0.0-rc6, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
related to DOCS-11794 reIndex now takes a Global exclusive ... Closed
is related to SERVER-44026 Remove global X lock for reIndex Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Backport Requested:
v4.0
Sprint: Storage NYC 2018-06-18
Participants:
Linked BF Score: 72

 Description   

reIndex does writes (both timestamped and untimestamped) but it does not acquire new optimes for such writes; it just piggybacks on whatever the current logical clock time is.
This renders the minimumVisibleSnapshot mechanism somewhat ineffective, since that requires new timestamps to be created for each write that is to be protected.
Because multi-document transactions establish a snapshot protected only by a Global lock and not a Database lock, it is possible to establish a snapshot in between a begin-index-build write and a commit-index-build write performed by a reIndex. Because the snapshot read time can be outside the minimumVisibleSnapshot time on the collection, such a snapshot can then see that the in-memory catalog shows the index as being ready, even though the storage engine catalog will show the index as being not-ready. This discrepancy can cause problems, including invariant failures.



 Comments   
Comment by William Schultz (Inactive) [ 14/Jun/18 ]

As described in BF-9559, this fix may not be sufficient to fix the bug about transactions seeing invalid index data, since multi-document transaction snapshots are initially acquired without holding any locks. The suggested fix is to take proper global and database intent locks inside transactions before acquiring the transaction's snapshot.

Comment by Githook User [ 13/Jun/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-35569 reIndex should take a Global exclusive lock instead of just a Database lock

(cherry picked from commit 262a09efff3e9ef33cc56af1eed6a6d73afecc95)
Branch: v4.0
https://github.com/mongodb/mongo/commit/09102565d15e386d09b16f0f257b8148622fb63c

Comment by Githook User [ 13/Jun/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-35569 reIndex should take a Global exclusive lock instead of just a Database lock
Branch: master
https://github.com/mongodb/mongo/commit/262a09efff3e9ef33cc56af1eed6a6d73afecc95

Comment by Esha Maharishi (Inactive) [ 12/Jun/18 ]

Note that if reIndex never takes the DBLock, it will not do a databaseVersion check.

Generated at Thu Feb 08 04:40:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.