Bug 1041539

Summary: [RFE][swift]: Use WAL journal mode for sqlite
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/swift/+spec/consider-wal-mode-sqlite
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_new
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:37:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 16:51:38 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/consider-wal-mode-sqlite.

Description:

Use PRAGMA journal=WAL (keeping synchronous=NORMAL as is in db.py already) and remove the in-house pending change log for sqlite container listing updates. The sqlite3 wal file serves a similar function except (a) read queries can use it on the fly without having to update the core database/indexes, avoiding fsync() and contention; and (b) when the wal log is merged in the "checkpoints" they still don't block readers (e.g. container listings). The might require other PRAGMA statements to avoid affecting durability of other table changes aside from the 'object' one. Also the rsync code to fix corrupt DBs would need adjustment.

Specification URL (additional information):

None