On 30.12.2017 01:14, Keith Medcalf wrote:
One presumes that you mayhaps read the documentation?
"In WAL mode when synchronous is NORMAL (1), the WAL file is
synchronized before each checkpoint and the database file is
synchronized after each completed checkpoint and the WAL file header
is synchronized when a WAL file begins to be reused after a
checkpoint, but no sync operations occur during most transactions.
With synchronous=FULL in WAL mode, an additional sync operation of the
WAL file happens after each transaction commit. The extra WAL sync
following each transaction help ensure that transactions are durable
across a power loss. Transactions are consistent with or without the
extra syncs provided by synchronous=FULL. If durability is not a
concern, then synchronous=NORMAL is normally all one needs in WAL
mode."
So, the question is whether or not you want D in your ACID. If all
you need is ACI, then synchronous=NORMAL guarantees that.
synchronous=FULL adds the D to your ACI giving you ACID.
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.
Supposing I am able to determine if the MODIFY operation is or is not an
actual disk write (a quick look at the inotify API suggests this is not
possible, I next have to look at the filesystem APIs), I may or may not
have to operate my own in-memory WAL as previously discussed to avoid
this unwanted behavior. Regardless, it may be that I'm attempting to
squeeze too much savings out of a delayed sync operation to begin with,
and need to look towards another method to begin with.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
