[SERVER-31726] Timestamps can be set on transactions that don't trigger a visibility refresh Created: 26/Oct/17  Updated: 30/Oct/23  Resolved: 27/Oct/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.6.0-rc2

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage 2017-11-13
Participants:
Linked BF Score: 0

 Description   

Currently the code expects all timestamped transactions, which have the potential to update visibility, to call WiredTigerOplogManager::triggerJournalFlush. There are code paths that can set timestamps but not result in calling this method.

Some paths forward to consider include:

  1. A call to WiredTigerRecoveryUnit::setTimestamp immediately installs the journal flushing "change". One drawback to this is that some recovery units have their timestamp set multiple times. Care should be taken to not create multiple unnecessary "changes".
  2. Remove OplogInsertChange and have WiredTigerOplogManager::triggerJournalFlush be called directly by all timestamped recovery units before returning from _txnClose.
  3. Relax the WiredTigerOplogManager::_oplogJournalThreadLoop conditions to run a refresh loop. E.g: always run an iteration every 5 seconds even if it hasn't been notified.


 Comments   
Comment by Githook User [ 27/Oct/17 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-31726: Trigger an OplogManager flush directly after transaction completion.

Readers have the ability to wait for oplog writes to become visible. The
visibility can be updated when a transaction commits or rolls back. There is a
background thread that polls WiredTiger for the visibility and publishes it to
readers.

For efficiency reasons, this background thread waits on a condition variable and
only iterates when notified. Previously, this notification was done via a "change"
callback on the recovery unit that is registered when a transaction writes its
entry to the oplog. However, there were (error) code paths where a transaction
finishing could have an impact on visibility, but not yet reached the point where
the callback was registered.

This patch fixes that error case by having transactions that can impact visibility
directly trigger the background thread when they complete.
Branch: master
https://github.com/mongodb/mongo/commit/528fd32f3aef9d273fb0ed34c5d78a87a9eeb240

Comment by Githook User [ 27/Oct/17 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-31726: Trigger an OplogManager flush directly after transaction completion.
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/e64f8da69715b4c95f3ae3de831d07180f190175

Comment by Eric Milkie [ 26/Oct/17 ]

I think Dan and I agree that number 2 in the description is the best way forward.

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