>>>>> "kern" == Kern Sibbald <[EMAIL PROTECTED]> writes:
kern> Could you look to see if there is some way to set the
kern> synchronous value to a default? I cannot imagine that
kern> the author of SQLite would not provide some way to do
kern> so.
It's clear---from Dysmas de Lassus's message about the database
performance improvments achieved by Marc Cousin and Eric B---that
this is a moot point, but just to complete the record on SQLite's
SYNCHRONOUS pragmas...
Since the discontinued DEFAULT_SYNCHRONOUS pragma was precisely a
way to set a persistent synchronous value, my interpretation of
the explicit un-documentation of DEFAULT_SYNCHRONOUS ("To help
dissuide users of version 2.8 from employing this pragma, the
documentation will not tell you what it does") had been that the
author of SQLite had indeed decided not to provide any way to
change the setting persistently.
I was going to take up your suggestion to investigate further,
but my search for SQLite mailing lists where I could pose the
question turned up an archived message from D. Richard Hipp,
SQLite's primary author, where he says:
"DEFAULT_SYNCHRONOUS no longer exists. The default setting for
synchronous is FULL. If you want something different, you have
to change it every time you open a new connection."
(http://www.mail-archive.com/sqlite-users@sqlite.org/msg03135.html)
which doesn't leave much room for doubt.
kern> If there is absolutely no way to set the default value,
kern> then I would certainly considering code as you are
kern> suggesting, but if a way to set the default exists, as
kern> I am 99% sure there is, then I would much prefer to
kern> leave it to the user to choose the degree of risk
kern> he/she wants to take and to manage it directly with the
kern> database.
I certainly agree that you do not want to impose on unsuspecting
users a setting that the author of SQLite considers so dangerous.
I was just sharing my information about the limited applicability
of the manual's advice to try "PRAGMA synchronous = NORMAL".
The patch to "configure" was my expedient (as a person who builds
bacula from source) for opting for a higher degree of risk, but I
can see that making the option available to users of prebuilt
binaries would require something set at configuration time rather
than compile time. I also understand that it is much better
if restructuring the catalog queries can reduce the number of
transactions to the point were the setting of the SQLite's
SYCHRONOUS pragma is immaterial.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
