On Sat, May 29, 2010 at 3:49 PM, Darren Duncan <dar...@darrenduncan.net>wrote:
> > 2. Quoth the raven: > > "The wal-index greatly improves the performance of readers, but the use > of > shared memory means that all readers must exist on the same machine. This > is > why the write-ahead log implementation will not work on a network > filesystem." > > I don't understand the need to sacrifice WAL on a network filesystem. My > naive > interpretation of the situation is that WAL itself would work on a network > filesystem, but just that processes using it that way would have slower > performance as they can't use the wal-index. > Correct. All clients that have the database open must be on the same SMP. The easiest way to enforce that is to just say "no network files". Note that the current implementation uses mmap() on an ordinary file to get shared memory. We may well change that to use shm_open() before the release. Does anybody know if mmap() works for network files? > 3. Quoth the raven: ... > > I don't understand the need for checkpointing to be an all-or-none affair. > We've been working on an incremental checkpointing mechanism for about a week. With incremental checkpointing, the checkpoint can be run more or less continuously in a background thread or process. Writers never block readers, readers never block writers, and checkpointers never block anybody. There can still only be one writer at a time, though, so writers still block other writers. And during recovery from a crash, everybody is blocked, but that's an unusual case. You can arrange for a fiendish sequence of overlapping reads and writes that prevent the checkpointer from making any progress and hence cause the WAL to grow without bound. But we do not anticipate that being a problem in the common case. If you set synchronous=NORMAL, then the checkpoint thread/process is the only thread/process that ever calls fsync() so you can do queries and updates in a GUI thread with much less risk of freezing the system due to a slow disk. You pay for this by giving up durability following a power-loss/hard-reset. Please note that SQLite databases with WAL will continue to feature fully automatic recovery from power-loss or hard-reset; applications do not have to do anything special to recover from a crash. Also, any client (reader, writer, or checkpointer) can take a SIGKILL at any instant and the system will automatically recover and continue operating. Code for the above will appear in the source tree soon, I hope - initially in a branch and then on the trunk as it stabilizes. -- --------------------- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
