406087 - upgrade to latest sqlite (currently 3.5.4)

Status: RESOLVED FIXED

(Core :: SQLite and Embedded Database Bindings, defect, P1)

Description

[(not reading, please use [e-mail] instead)]

upgrade to latest sqlite (currently 3.5.3)

see also bug #393959

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

3.5.4 is out. As the news page goes, "Upgrading is recommended for all users."

Comment 2

[(not reading, please use [e-mail] instead)]

thanks for the heads up, Gary.

From a quick scan of http://www.sqlite.org/releaselog/3_5_4.html, I don't see any security vulnerabilities.

Two that caught my eye:

1)

"Fix a critical bug in UPDATE or DELETE that occurs when an OR REPLACE clause or a trigger causes rows in the same table to be deleted as side effects. (See ticket #2832.) The most likely result of this bug is a segmentation fault, though database corruption is a possibility."

Recently, dietrich added a "INSERT OR REPLACE" usage in places, so I think we (in places) are safe.  but a quick LXR shows we might have one instance of "UPDATE OR REPLACE"

/netwerk/cache/src/nsDiskCacheDeviceSQL.cpp, line 800 -- StatementSql ( mStatement_SwapClientID, "UPDATE OR REPLACE moz_cache SET ClientID = ? WHERE ClientID = ?;")

so we might need that fix for some of the offline code (cc'ing dcamp)

http://www.sqlite.org/cvstrac/tktview?tn=2832

2)

Better optimization of some IN operator expressions.

I think Marco has a patch to switch from "visit_type <> 0 AND visit_type <> 4" to "visit_type NOT IN (0,4)"

Marco, since we are not using 3.5.4, does this mean we should hold off on this optimization?

Comment 3

[Marco Bonardo [:mak]]

there is no difference now in using AND or IN (from a perf point of view), i've changed them to use the same syntax in all queries (some queries were using IN some AND), don't know if moving to 3.5.4 will make that faster in some way, the definition "Better optimization of some IN operator expressions" is too generic to tell, but we have also many IN operators in expiration queries, so that could help (not critical though).

Comment 4

[Mike Schroepfer]

want this asap..

Comment 5

[Shawn Wilsher :sdwilsh]

Attachment: v1.0 our changes

This is all we need to change on our end to update to the latest.  Stuart may want to take advantage of sqlite3_release_memory for his addon, and others may find that useful in general.

Patch with sqlite changes momentarily.

Comment 6

[Shawn Wilsher :sdwilsh]

Attachment: v1.0 sqlite

Comment 7

[Shawn Wilsher :sdwilsh]

Comment on attachment 296338 [details] [diff] [review]
v1.0 sqlite

whoops - wrong diff

Comment 8

[Shawn Wilsher :sdwilsh]

The real one is too big to attach.  For those interested, you can see it here:
http://files.shawnwilsher.com/2008/1/10/sqlite.patch
This doesn't need review though.

Comment 9

[Shawn Wilsher :sdwilsh]

I just submitted this to the try server.  I'll make sure we build OK before I go ahead and land this.

Comment 10

[Shawn Wilsher :sdwilsh]

Wooo!

Checking in db/sqlite3/README.MOZILLA;
new revision: 1.18; previous revision: 1.17
Checking in db/sqlite3/src/sqlite.def;
new revision: 1.5; previous revision: 1.4
Checking in db/sqlite3/src/sqlite3.c;
new revision: 1.9; previous revision: 1.8
Checking in db/sqlite3/src/sqlite3.h;
new revision: 1.14; previous revision: 1.13