Re: [sqlite] Exposing sqlite3BtreeCommitPhaseOne

[Dan Kennedy]

> Currently if an interrupt
> arrives during a long commit I have no way to know whether the commit
> was successful, and thus whether to commit or roll back the filesystem
> journal.

Maybe you can read the database to see if the new data
is there in this scenario.

> If I could flush the dirty pages first, then the actual commit
> is short enough to be effectively instantaneous and there's little
> chance of an interrupt arriving at the same time.

Roughly the same chance of an interrupt arriving during the
COMMIT and the COMMIT still being successful, no?

> Would it be possible to expose this first phase via a C or SQL API?

It's not an unreasonable suggestion, but it seems like the kind
of thing that won't happen to me.

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Exposing sqlite3BtreeCommitPhaseOne

[Michael Tharp]

Hello,

I'm looking for a way to force sqlite to do its internal "phase one 
commit", which apparently flushes dirty pages to disk without committing 
the journal. This way I can minimize the time spent in the "phase two 
commit", which is the point at which the journal is unlinked and the 
changes become permanent.

I need this in a package manager to synchronize a sqlite database with a 
journal of changes made to a filesystem. Currently if an interrupt 
arrives during a long commit I have no way to know whether the commit 
was successful, and thus whether to commit or roll back the filesystem 
journal. If I could flush the dirty pages first, then the actual commit 
is short enough to be effectively instantaneous and there's little 
chance of an interrupt arriving at the same time.

Would it be possible to expose this first phase via a C or SQL API?

Thanks!

-- 
Michael Tharp
rPath, Inc.
mth...@rpath.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users