Closed Bug 487664 Opened 11 years ago Closed 11 years ago

Upgrade to SQLite 3.6.13

Categories

(Toolkit :: Storage, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
mozilla1.9.2a1

People

(Reporter: sdwilsh, Assigned: sdwilsh)

References

Details

Attachments

(1 file)

No description provided.
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.
Flags: blocking1.9.1?
Priority: -- → P1
3.6.13 is out, so I just need to make a patch
Whiteboard: [needs patch]
Attached patch v1.0Splinter Review
Running tests now locally to make sure everything is still OK.
Attachment #372403 - Flags: review?(bugmail)
Whiteboard: [needs patch] → [needs review asuth]
Blocking for beta as per comment 1 and Shaver's suggestion, might unblock if we can't get it to integrate on time.
Flags: blocking1.9.1? → blocking1.9.1+
Attachment #372403 - Flags: review?(bugmail) → review+
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.
Whiteboard: [needs review asuth] → [can land]
Hrm...must have forgotten to qrefresh before making the diff.  My bad!
Blocks: 448658
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.
http://hg.mozilla.org/mozilla-central/rev/629e0c724413
http://hg.mozilla.org/mozilla-central/rev/7b4e5f6006a3
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Priority: P1 → P3
Resolution: --- → FIXED
Whiteboard: [can land]
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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Depends on: 488887
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!
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → WONTFIX
Filed bug 489442 tracking the upgrade to 3.6.14
You need to log in before you can comment on or make changes to this bug.