> 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
