Bug 353171
| Summary: | non-existence of *.sqlite-journal not cached during install | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Reiser <jreiser> |
| Component: | yum | Assignee: | Seth Vidal <skvidal> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | ffesti, james.antill, katzj, pmatilai, tim.lauridsen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-25 20:40:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
John Reiser
2007-10-25 20:10:10 UTC
Is there a way we can tell sqlite that there's not going to be a journal file so it should not bother looking for one over and over again? Checking for journal existence is part of sqlite locking mechanism (see http://www.sqlite.org/lockingv3.html, "dealing with hot journals"). AFAICT the only way to avoid checking for the journal is grabbing an exclusive lock on the db (doable at least with "begin exclusive" SQL-statement) but I suppose that'd have to be done on yum-level and that in turn would probably have some other, not necessarily wanted, implications... Actually, I don't know why we wouldn't want that. At the yum level, we already grab a global lock and don't allow other (correct :-) API users to do operations at the same time. So locking the sqlite dbs also doesn't seem unfair. Well, a quick experiment of sticking the below sledgehammer-approach patch to
yum-metadata-parser cuts down the tests for journal existence on "yum
--enablerepo=updates-testing update" on my box ATM from 5488 to 7 :)
--- sqlitecachec.py.orig 2007-12-22 15:58:48.000000000 +0200
+++ sqlitecachec.py 2007-12-22 16:20:44.000000000 +0200
@@ -31,6 +31,9 @@
con = sqlite.connect(filename)
if sqlite.version_info[0] > 1:
con.row_factory = sqlite.Row
+ cur = con.cursor()
+ cur.execute("pragma locking_mode = EXCLUSIVE")
+ del cur
return con
def getPrimary(self, location, checksum):
With sufficiently large number of accesses, it starts to even show up in
wallclock times: in apt-rpm usage patterns exclusive access to sqlite db cuts
something like ~7% from a full cache rebuild time. Yum's usage patterns are
wildly different but it can't hurt there either...
panu, thank you for the patch, I've applied it to y-m-p and I'm going to check put it in rawhide shortly. |