[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] fsync on -wal still happening
From:       "Keith Medcalf" <kmedcalf () dessus ! com>
Date:       2017-12-30 17:21:45
Message-ID: 827020d155c96b4e861c528846974fbf () mail ! dessus ! com
[Download RAW message or body]


> Naturally, and of course. The point of my initial post was that I was
> still seeing sync operations with synch=NORMAL when I shouldn't have
> according to the below docs (now debatable whether they were actually
> written to disk or just the os cache). I purposely configured synch
> to
> NORMAL to avoid the additional sync to the -wal file, but was still
> seeing it in operation.

Interesting.  In fact I believe I saw the same problem/issue with batch loading of a \
"bunch" of files into a database.  Re-running the update is not a problem but \
database consistency was.  Interestingly, I ended up using savepoint's for each batch \
and doing one commit to the WAL file.  The I/O rate was greatly reduced even though \
the update (import) touched a whole raft of database pages.  This used \
synchronous=normal.  If something crashed the database was consistent and the "load" \
operation could simply be done again.  (I/O rate was reduced from huge multi MB/s \
with the begin-commit to the KB/s with the savepoints and there did not appear to be \
any fsyncs other than when the transaction was committed (which also did a \
checkpoint)).

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot \
about anticipated traffic volume.



_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[prev in list] [next in list] [prev in thread] [next in thread]