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.

Reply via email to