Thanks for your detailed reply. Would you mind answering my follow up queries?
> The ability to disable journaling is not a supported behaviour of > SQLite. If you can get it to work, that's great. But if not, that > is not considered a bug. Ok so the ability to not be able to disable journaling is not a bug. However would you consider implementing this as a new feature in a future revision of SQLite? I am unsure how many other users would find the disabling of the journal file a useful feature? I know here we would really appreciate this. We have seen information on the web indicating that turning off journaling would help performance, See section 3.3 at http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html. Although it does not state a mechanism for doing so. So maybe there are other users that would appeciate this as well as us? Indeed not journaling the file did help performance a great deal, but of course we have to prioritise data integrity over speed. We do believe however that journaling the database for us is of no benefit as our filing system is 100% fail safe and will return to the last flushed state of the file on power loss. Ideally we want to be able to use the latest versions of SQLite as they are released and as such don't want to stay with 3.2.1 especially as we may have been inadvertently benefiting from what was actually a bug anyhow. Regards Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 01 November 2005 11:49 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] disabling journalling of the database - side > affects? > > > "Allan, Mark" <[EMAIL PROTECTED]> wrote: > > I definately have a problem when I disable journalling on > version 3.2.7 > > of SQLite. I dont see the same problem with 3.2.1 of SQlite. > > I disable the journalling of the database file as described in my > > earlier email. > > With version 3.2.7 this causes SQlite to not sync the database file > > after some updates (i.e. sqlite3OsSync() is not called). This means > > that if power is lost before the database file is explicitly closed > > we are losing those changes. > > > > I realise that the purpose of the journal file is to allow > the database > > to return to its last valid state if power is lost during an update, > > however we believe that in our system we will not need this as our > > flash filing system is 100% power safe. i.e. it will return to the > > last flushed state of the file on power loss. So we believe that not > > only is the journalling of the database time consuming it is also > > unnecessary for us, which is a little annoying. > > > > If this is a bug in 3.2.7 of SQlite can it be fixed? If I cannot > > disable the journal file safely by the mechanism described in my > > previous email then can somebody please indicate how I can disable > > journalling of the database safely. > > > > The ability to disable journalling is not a supported behavior of > SQLite. If you can get it to work, that's great. But if not, that > is not considered a bug. > > The omitJournal flag on sqlite3BtreeFactory() is used for transient > tables that are never rolled back and which we do not care about if > there is a program crash or power failure. The system should never > call sqlite3OsSync() on such files because sqlite3OsSync() is an > expensive operation (on most platforms) and for a transient file > it does not accomplish anything useful. If version 3.2.1 was calling > sqlite3OsSync() on unjournalled files, then that was a performance > bug. I have no specific memory of fixing that problem in 3.2.7, but > a lot of little problems were fixed in between those two releases, > so it seems plausible that this was one of them. > > So my best guess is that if your journal-less use of SQLite worked > with version 3.2.1 then that was due to a bug in 3.2.1 that has > since been fixed - not a bug that has been introduced. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > DISCLAIMER: This information and any attachments contained in this email message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, forwarding, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email, and delete the original message immediately.
