We have some questions about the "synchronous" pragma and
how it should work in version 3.0.  Feedback from the user
community is welcomed.

First some review:

The synchronous pragma determines how agressive SQLite is
about making sure data really reaches the surface of the
disk drive as opposed to just being stored in the operating
systems filesystem cache.  There are three possible
settings:

   PRAGMA synchronous=off;
   PRAGMA synchronous=on;
   PRAGMA synchronous=full;

When synchronous is OFF, no effort is made to flush data
to the disk.  This means an unexpected power loss or an
OS crash can corrupt the database.  When synchronous is
ON, data is flushed to disk at key points so that the
database is (usually) safe from corruption during a power
loss.  FULL synchronous does some additional disk flushes
in order to guard against a race condition that can lead
to database corruption following a power failure on
unjournalled filesystems.

Generally speaking, writes happen faster when synchronous
is OFF, but at the price of a serious risk of database
corruption following a power failure.  ON is a little
faster than FULL, but not by much.  Most users will not
notice the difference between ON and FULL.

There are actually two synchronous pragmas.  The normal
"synchronous" pragma only effects the current session.
When the database is reopened, the synchronous setting
reverts to what it was.  A second "default_synchronous"
pragma changes the synchronous setting persistently.

QUESTION 1:
The default setting in version 2.8 is ON.  For version 3.0
we propose to change the default synchronous setting to FULL.
Does anybody have any problems with this?

QUESTION 2:
We propose to eliminate default_synchronous and have the
regular synchronous pragma change the synchronous setting
persistently.  Does anybody have any problems with this?

--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to