I was told by shaver that I should request blocking on this so we can get beta coverage on the fsycn->fdatasync change. I've talked to the SQLite folks, and since we are consortium members, they will rush 3.6.13 for us, and should have it out Tuesday afternoon. I also pushed their latest CVS head with the fix from bug 487660 to the try server to make sure no more unit tests are failing. If other issues are found, we will be depending on a third party for a P1 beta blocker, so drivers should keep that in mind.
3.6.13 is out, so I just need to make a patch
Created attachment 372403 [details] [diff] [review] v1.0 Running tests now locally to make sure everything is still OK.
Blocking for beta as per comment 1 and Shaver's suggestion, might unblock if we can't get it to integrate on time.
Comment on attachment 372403 [details] [diff] [review] v1.0 >diff --git a/db/sqlite3/README.MOZILLA b/db/sqlite3/README.MOZILLA >--- a/db/sqlite3/README.MOZILLA >+++ b/db/sqlite3/README.MOZILLA >@@ -1,11 +1,11 @@ >-This is sqlite 3.6.10 >+This is sqlite 3.6.12 ^ nit: 3.6.13 patch in your queue is confirmed 3.6.13 and unit tests pass.
Hrm...must have forgotten to qrefresh before making the diff. My bad!
sdwilsh: we getting this in on trunk today and branch later tonight?
(In reply to comment #7) > sdwilsh: we getting this in on trunk today and branch later tonight? That is the plan.
No noticeable change on Talos for Linux Ts, or anything really. sadface
...and, I'm not presently convinced that these aren't just machine issues. More to come!
And it's out for real. Forgot to actually reopen the bug...
Turns out that the try server did show this regression. I must have been looking at different builds at the time. Current theory is that this is caused by not using any fdatasync's for the OS X code anymore. Apple told the SQLite developers that fdatasync is a noop, so it doesn't actually protect the database integrity at all. Yay. I'm running a test on the try server which should prove or disprove this theory.
(In reply to comment #13) > Turns out that the try server did show this regression. I must have been > looking at different builds at the time. What regression are you talking about? Your last comments here were really cryptic...
There was a Tp3 regression of 3-5% (depending on the machine you looked at) when this landed on OS X.
So far, we've isolated the regression to one change in SQLite: http://www.sqlite.org/cvstrac/chngview?cn=6197 Working with the SQLite guys to resolve this.
So, the regression has been identified. In the course cleaning up the pager.c module, they removed a test that didn't call ftruncate on a zero-length file. On linux, calling this method on a zero-length file takes nanoseconds. On OS X, it's a totally different story. Yay.
We clearly won't be taking this, so WONTFIX. Look for an upgrade to 3.6.14 soon!
Filed bug 489442 tracking the upgrade to 3.6.14
(In reply to comment #9) To be explicit, these were backed out: > http://hg.mozilla.org/mozilla-central/rev/629e0c724413 http://hg.mozilla.org/mozilla-central/rev/f6ad2bc5ef2a > http://hg.mozilla.org/mozilla-central/rev/7b4e5f6006a3 http://hg.mozilla.org/mozilla-central/rev/75cd2018d4bc