sqlite: Use SQLite's API for getting per-database page pools.
Chrome currently carries a SQLite patch at 0002-Use-seperate-page-cache-pools-for-each-sqlite-connec.patch which forces per-database (technically, per-connection) page cache pools. Asides from adding to our maintenance burden, the patch breaks an assert() in SQLite's code, suggesting that it doesn't work as intended anymore. Fortunately, SQLite has a few supported ways of specifying whether database connections use private page cache pools or a central pool. The most convenient method for Chrome is the SQLITE_OPEN_PRIVATECACHE flag on sqlite3_open_v2() [1]. This CL does the following: 1) Removes the SQLITE_SEPARATE_CACHE_POOLS build flag, which activates Chrome's page cache pool patch. The patch (which becomes inert when this CL lands) shall be removed from our SQLite version in a follow-up CL, after this CL sticks. 2) Removes the SQLITE_ENABLE_MEMORY_MANAGEMENT build flag. This flag is incompatible with private page cache pools, because it enables the sqlite3_release_memory() function [2], which assumes a centralized (shared) page cache pool [3]. Chrome doesn't use sqlite3_release_memory() today, so the flag is unnecessary. If we want to trim SQLite caches in response to memory pressure, we can still use sqlite3_db_release_memory() [4] and track all the open connections ourselves. 3) Adds the SQLITE_OPEN_PRIVATECACHE flag to our invocation of sqlite3_open_v2(). [1] https://www.sqlite.org/c3ref/open.html [2] https://www.sqlite.org/c3ref/release_memory.html [3] https://www.sqlite.org/sharedcache.html [4] https://www.sqlite.org/c3ref/db_release_memory.html Bug: 906396 Change-Id: Ib3b08b26364ad86d173111fc4e554bd07bd91aa1 Reviewed-on: https://chromium-review.googlesource.com/c/1343789Reviewed-by:Joshua Bell <jsbell@chromium.org> Commit-Queue: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#609754}
Showing
Please register or sign in to comment