For "filesystem nearly full" situations, where there are potentially other processes consuming and freeing space on the underlying device(s), you will have the same uncertainty regarding subsequent retries whether or not you are able to get an error code more specific than SQLITE_FULL. Using the OS calls to determine available free space is not going to change that. In the thread you cite, (and your original post in this thread, I suppose), the term "recoverable" is used differently, and more restrictively, than I interpreted it. Of course there is going to be no recovery if that means succeeding with the same operation where nothing else changes. Considering the disk full case(s): As was mentioned in that other thread, recovery will normally require freeing some disk space, something that your program is not likely able to do in a desirable manner. It will need to give up or pause while some more knowledgeable person or program deals with and perhaps alleviates the problem. Considering the page count limit reached case: I think that if you have set the page count limit lower than its maximum, with the intention of using that as trip-wire to do some sort of cleanup likely to reduce used page count, then you need not worry about precisely how much larger the page count can get relative to need. Recovery will be to do whatever cleanup of log data, materialized views, caches, and etc. that will get the page count back down to a "usable" level. Even if this is done when additional pages were low and that was not the direct cause of the SQLITE_FULL problem, it will free up disk space also which has a good chance of alleviating the error. I am somewhat puzzled by your problem at this point. I think some real (or imagined likely) use cases would bring this discussion to a more concrete basis. Your phrase, "reliable way to handle this issue", leads me to wonder what "reliable" can possibly mean in this context. It begs for a clearer definition.