Hallvard Breien Furuseth wrote:
Howard Chu writes:
Setting the latest commit becomes atomic: Just change metapos. (Field MDB_txninfo.mti_txnid goes away.)
The latest commit is already atomic. mti_txnid is updated atomically in the current code.
No sync issues with copying 'MDB_db's from the meta, since the meta will not be overwritten during the txn.
There are no sync issues in the current code.
I may have been thinking of the same thing with these two, but maybe I'm out of date.
OK, preserving consistency is potentially a win vs what we have now. But it's also more of a crapshoot - you're only providing ACI, not D, and the application won't hear about the loss of D until long after the fact.
Some applications can probably tolerate this. But is it something we want to deal with?
Then I'm not sure what's the point of so many speedup options like it has now.
MDB_NOSYNC is perfectly safe on some filesystems like ZFS that guarantee write order.
Some apps want the ability to return immediately from txn_commit while performing syncs in a background thread. MAPASYNC lets us do that. What you're talking about may also do that. I just want to be clear about the motivation and the expected benefit.
Using variably positioned meta pages seems like something we would try to cut down on seek overhead, but looking closer it doesn't appear that it can do that.