On 06/23/2015 12:01 PM, Mayank Kumar (mayankum) wrote: > Thanks Simon. My application has synchronous set to FULL. It seems sqlite > tries to do fsync for read operations as well since I also got this error > when executing "select * from db". > My application currently treat this error 1034(disk io error) as catastrophic > error and dies. > > Do you think if sqlite3_step or sqlite3_open fail with this error, we should > treat this as transaction committed and ignore the fsync error and it will be > retried with the next commit or read and eventually will sync unless I see > this error continuously in which case we can treat this as catastrophic.
The fsync() within the SELECT statement is likely happening as part of rolling back a hot-journal. i.e. it is attempting to restore the database to a sane state following a transaction that failed due to an earlier IO error. On the platform in question, is there any reason to think the system will recover once fsync() starts failing? Treating this as a catastrophic error would usually be the right way to go. Dan > > Also I wanted to know if fsync requires space on the filesystem since in our > case nvram has little space(200mb), do you think fsync could fail because of > that as well? > > Thanks > mayank > > > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon > Slavin > Sent: Monday, June 22, 2015 6:11 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] sqlite error code 1034 > > > On 23 Jun 2015, at 1:33am, Mayank Kumar (mayankum) <mayankum at cisco.com> > wrote: > >> We once in a while see the following errors returns by sqlite for a database >> created on nvram. I am trying to understand, how are other users handling >> this error ? if fsync fails and sqlite api fails because of this issue, does >> sqlite internally retry before declaring it cannot commit a transaction >> because of this and should the application retry or this is a non >> recoverable error ? >> I know if the os fsync fails, we cannot guarantee the db remains sane and >> uncorrupted, in case of os crash or shutdown, but just trying to see what >> others are doing for their applications in this scenario. > There's no easy way to retry the operation which failed, but you probably > don't have to. > > I have not encountered fsync() failure as part of SQLite, but to a unix user > it is the same as 'IO Error'. There is no point in retrying it since it will > effectively be retried on the next operation of the file, including when the > file handle is closed. So there is a good chance that the file will > eventually be synchronised anyway. Problems may, however, occur if you have > multiple apps/users trying to access the file at once. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
