This feature is enabled by default, but is gated behind a new base
feature flag. It builds on the changes behind the kClearDbIfCloseFails
flag. Rather than adding a new flag whose value would depend on this
older flag, this CL simply removes the older flag, which has been on
stable for almost two milestones and is therefore removable according
to the flag-guarding guidelines.
Bug: 1441955
Change-Id: Idabc75fc69250976a907dfe4e554cc9f204b21fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4499396
Commit-Queue: Austin Sullivan <asully@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1184284}
This new method decides internally whether to use the new
`sql::BuiltInRecovery` or the legacy `sql::Recovery`, based on
feature flags and availability. It is intended to facilitate the
migration to the newer recovery module with minimal impact on feature
teams. The expectation is that the branch which uses `sql::Recovery`
will eventually become obsolete and be removed entirely.
Adds a new kill switch which may disable all use of `BuiltInRecovery`
if necessary.
Also updates the test suites to remove use of `if (!BuiltIn()) ...`
Bug: 1385500
Change-Id: Idaeab746c7a257b1eda2f1ec02c6525c7473bcdc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4570917
Reviewed-by: Evan Stade <estade@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1151027}
According to https://www.sqlite.org/c3ref/open.html:
A database connection handle is usually returned in *ppDb,
even if an error occurs.
Unfortunately, is_open() simply checks whether the database connection
member exists, which means that is_open() effectively behaves as
has_called_sqlite3_open_v2()
As a follow-up, we should consider making is_open() check poisoned_
Bug: 1423640, 1441955
Change-Id: Ia29b1d42e4f0bff2580af53d2804b569b28c2de9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4499308
Reviewed-by: Evan Stade <estade@chromium.org>
Auto-Submit: Austin Sullivan <asully@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1139641}
This allows:
- features to be defined with a consistent set of qualifiers, and for
that set of qualifiers to be updated over time as appropriate.
- better PRESUBMIT checks to ensure that base::Features are not defined
in headers.
- simplifies things for scripts trying to extract feature definitions
out of C++ code.
The primary CL was generated using a script that automatically rewrites
base::Feature declarations and definitions to the macro form. Changes to
any files with known incompatibilities with the macros (base::Features
without static storage duration and base::Features declared as static
class members) were then fully reverted; those changes will be manually
handled in followups.
This CL was uploaded by git cl split.
R=asully@chromium.org
Bug: 1364289
Change-Id: Ib72314440a729540f22a58022fab85cab5dc6a19
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3923023
Auto-Submit: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Austin Sullivan <asully@chromium.org>
Commit-Queue: Austin Sullivan <asully@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1052139}
As per issue 78507, we are looking to add support for SQLite databases
to use Write-ahead logging (https://www.sqlite.org/wal.html) mode in
Chromium. WAL mode should give us significant performance gains across
almost all use-cases.
This change is a first step towards achieving this. It adds opt-in
support to enable WAL mode for a database connection and perform a
checkpoint. It also adds a feature flag to enable WAL mode for all
databases by default to investigate its feasibility and impact on
performance.
Bug: 78507
Change-Id: I7fc5edcc39b50d2a13755d587cf342bded1af60a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095927
Commit-Queue: Shubham Aggarwal <shuagga@microsoft.com>
Reviewed-by: Brandon Maslen <brandm@microsoft.com>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Reviewed-by: Chris Mumford <cmumford@google.com>
Cr-Commit-Position: refs/heads/master@{#780318}
The logic in sql::Database::Preload() is a pessimization for modern OS
schedulers, as it forces the kernel to read the first few pages of a
newly opened database. https://crbug.com/243949 suggests that this
method was added without performance testing, just like the more complex
SQLite patch that it replaces.
This CL sets up a Finch trial that will either prove that we can get rid
of the Preload() hack, or give us conclusive data about its usefulness.
Bug: 243949
Change-Id: Icfee9aaa3d125af207974536e8e5f5e64a9609ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1438031
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Chris Mumford <cmumford@google.com>
Commit-Queue: Steven Holte <holte@chromium.org>
Auto-Submit: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#662006}
This CL introduces SqlTempStoreMemory flag, which is intended to be
managed via Finch. When set, the flag causes sql::Database to run a
PRAGMA temp_store=MEMORY [1] query on every opened database.
This approach is intended to approximate the effect of building SQLite
with the SQLITE_TEMP_STORE=3 [2] macro, to measure the memory
consumption impact. Ideally, we'd test the macro directly, but //sql is
a core component of Chrome, so we can't load different versions of it
based on Finch.
[1] https://www.sqlite.org/pragma.html#pragma_temp_store
[2] https://www.sqlite.org/compile.html#temp_store
Bug: 875538
Change-Id: I537d90d763be1100503ed4bd2ada2ee19eb090bb
Reviewed-on: https://chromium-review.googlesource.com/1180530
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Chris Mumford <cmumford@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584652}
