Since this doesn't provide a -journal file, certain kinds of crashes cannot be recovered correctly.
Why you you hard-link before the commit? The schema doesn't exist until the commit is successful, so there's no advantage to anyone else reading the file before then. As far as preventing the other process from using it before the schema exists, do "SELECT count(*) FROM sqlite_master", and if the result is 0, the schema does not exist. If you create the schema as a transaction, that will be atomic. -scott On Mon, Jan 11, 2016 at 10:25 AM, Felipe Gasper <felipe at felipegasper.com> wrote: > Hi all, > > To prevent race conditions where a 2nd process accesses a > newly-created SQLite file before the creator process can set up the schema, > I?ve implemented logic like this: > > - create SQLite file as a .tmp beside permanent location > > - BEGIN EXCLUSIVE LOCK > > - hard-link the temp file to the permanent location > > - create schema > > - COMMIT > > - unlink temp file > > This prevents the problem because the permanent file never exists > unlocked prior to the schema existence. The 2nd process would either fail > to open the DB because it?s locked or open it and see the schema. > > I?m seeing some corruption in our SQLite files now but have had a > hard time tracking down the cause. Could it be because of the above logic? > What have folks here done to avoid the race condition originally described? > I?ve seen some documentation of SQLite and hard links but > > -FG > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
