Database Corrupt While Disk Full

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Database Corrupt While Disk Full

sanhua.zh
Recently, my monitoring system showed that the error code SQLITE_FULL and SQLITE_CORRUPT increasing in same trend. And thousands of users, who’s database is corrupt, also traped inlow disk free space and their log show that SQLITE_IOERR, SQLITE_FULL happenedsimultaneously.


I confuse that whether disk full willcorrupt the database (may be indirectyly).


Background:
This is happened in iOS. The OS will automatically clean the disk cache to make some spacewhile disk free space is low. But disk may still be full while all disk cache has been cleaned.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Simon Slavin-3

On 14 Jan 2016, at 8:44am, sanhua.zh <[hidden email]> wrote:

> Recently, my monitoring system showed that the error code SQLITE_FULL and SQLITE_CORRUPT increasing in same trend. And thousands of users, who’s database is corrupt, also traped inlow disk free space and their log show that SQLITE_IOERR, SQLITE_FULL happened simultaneously.

Once you have received SQLITE_CORRUPT once, the database is corrupt and you should no longer use it.  Later commands may return SQLITE_OK but that just means that they didn't read the corrupt part of the database.  Somewhere else in the database file it is still corrupt.

> I confuse that whether disk full will corrupt the database (may be indirectyly).

Not always ("will"), but sometimes (might).  It depends on what SQLite is doing when it finds no spare space.

However, if this happens

1) The program returned SQLITE_IOERR or SQLITE_FULL then crashed
2) you deleted some files to make some free space
3) you restart the program
4) the program works without returning any other SQLite error

SQLite has returned the database to an uncorrupted state by rolling back the last transaction before the crash.  This cannot happen if the error is instead SQLITE_CORRUPT.  That result always means that the database is corrupt in a way that SQLite will not automatically fix.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

sanhua.zh
In reply to this post by sanhua.zh
Thanks for your answer.


Through the error code timeline, it shows that much of SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT. Database might be in an obscure state while disk is full, then it corrupt in some unknown reason.


As you said, disk full might corrupt the database. Can you teach me a little more in detail ? I haven’t found the relative code in SQLite source code.


原始邮件
发件人:Simon [hidden email]
收件人:SQLite mailing [hidden email]
发送时间:2016年1月14日(周四) 17:46
主题:Re: [sqlite] Database Corrupt While Disk Full


On 14 Jan 2016, at 8:44am, sanhua.zh [hidden email] wrote:  Recently, my monitoring system showed that the error code SQLITE_FULL and SQLITE_CORRUPT increasing in same trend. And thousands of users, who’s database is corrupt, also traped inlow disk free space and their log show that SQLITE_IOERR, SQLITE_FULL happened simultaneously. Once you have received SQLITE_CORRUPT once, the database is corrupt and you should no longer use it. Later commands may return SQLITE_OK but that just means that they didn't read the corrupt part of the database. Somewhere else in the database file it is still corrupt.  I confuse that whether disk full will corrupt the database (may be indirectyly). Not always ("will"), but sometimes (might). It depends on what SQLite is doing when it finds no spare space. However, if this happens 1) The program returned SQLITE_IOERR or SQLITE_FULL then crashed 2) you deleted some files to make some free space 3) you restart the program 4) the program works without returning any other SQLite error SQLite has returned the database to an uncorrupted state by rolling back the last transaction before the crash. This cannot happen if the error is instead SQLITE_CORRUPT. That result always means that the database is corrupt in a way that SQLite will not automatically fix. Simon. _______________________________________________ sqlite-users mailing list [hidden email] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Stephan Beal-3
On Thu, Jan 14, 2016 at 10:58 AM, sanhua.zh <[hidden email]> wrote:

> Through the error code timeline, it shows that much of SQLITE_FULL,
> SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT. Database
> might be in an obscure state while disk is full, then it corrupt in some
> unknown reason.
>
>
> As you said, disk full might corrupt the database. Can you teach me a
> little more in detail ? I haven’t found the relative code in SQLite source
> code.
>

FWIW, the reason for the corruption is not unknown: your app continued to
use sqlite after (apparently) ignoring 3 different error codes (all of them
serious). That misuse is what corrupted it.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Simon Slavin-3
In reply to this post by sanhua.zh

On 14 Jan 2016, at 9:58am, sanhua.zh <[hidden email]> wrote:

> Through the error code timeline, it shows that much of SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT.

You should never get to this situation.  The three result codes SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN are fatal errors.  Your program should crash there, it must not try to continue using the database.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

sanhua.zh
In reply to this post by sanhua.zh
OK.
Manual crash might be a kind of solution.


BTW, how does SQLITE_FULL finally result in SQLITE_CORRUPT? How does it happen in detail?


原始邮件
发件人:Simon [hidden email]
收件人:SQLite mailing [hidden email]
发送时间:2016年1月14日(周四) 18:41
主题:Re: [sqlite] Database Corrupt While Disk Full


On 14 Jan 2016, at 9:58am, sanhua.zh [hidden email] wrote:  Through the error code timeline, it shows that much of SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT. You should never get to this situation. The three result codes SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN are fatal errors. Your program should crash there, it must not try to continue using the database. Simon. _______________________________________________ sqlite-users mailing list [hidden email] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Brice André
In reply to this post by Simon Slavin-3
Dear Simon,

I am a little worried with your last post because, I must admint that I do
not take special measures in my application when such errors occur to
guarantee that no more DB access are performed.

I have thus the following questions :

   1. What would be the proper reaction to SQLITE_FULL, SQLITE_IOERR,
   SQLITE_CANTOPEN ? Perform a sqlite3_close ? Just exit the program as is
   without touching the database file descriptor ? And once the program has
   left, can we perform a sqlite3_open ?
   2. What is the exhaustive list of error codes that shall be considered
   as fatal ?
   3. Is it documented somewhere ?

Thanks in advance,

Brice

2016-01-14 11:41 GMT+01:00 Simon Slavin <[hidden email]>:

>
> On 14 Jan 2016, at 9:58am, sanhua.zh <[hidden email]> wrote:
>
> > Through the error code timeline, it shows that much of SQLITE_FULL,
> SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT.
>
> You should never get to this situation.  The three result codes
> SQLITE_FULL, SQLITE_IOERR, SQLITE_CANTOPEN are fatal errors.  Your program
> should crash there, it must not try to continue using the database.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Simon Slavin-3

> On 14 Jan 2016, at 11:55am, Brice André <[hidden email]> wrote:
>
> I am a little worried with your last post because, I must admint that I do
> not take special measures in my application when such errors occur to
> guarantee that no more DB access are performed.
>
> I have thus the following questions :

If you're writing a proper long-term program, check the result codes returned by every SQLite API call.  In most cases all you need to do is check to see that the result is SQLITE_OK.  Hope this helps.

>   1. What would be the proper reaction to SQLITE_FULL, SQLITE_IOERR,
>   SQLITE_CANTOPEN ? Perform a sqlite3_close ? Just exit the program as is
>   without touching the database file descriptor ? And once the program has
>   left, can we perform a sqlite3_open ?

At this point there is no need to execute any other sqlite3_ calls.  In fact, if you do execute them they'll probably just return another error message.  Just print an error message and quit.

When the SQLite API is next used to open the file it will know that the file was not closed properly and automatically try to reconstruct an uncorrupted version.  This is done without informing the program that anything was wrong.  So your question is why should you not try to do this immediately ?  The answer is that without the user taking action it's probably going to fail.

The original crash might have reported SQLITE_FULL or some other other condition which the user needs to fix before reopening the database.  Trying to recover an uncorrupted database while the disk is still full will probably just lead to another crash, so there's no point and, at worst, a possibility of corrupting your database or some other file associated with the program.

Another possibility is that the error is something like SQLITE_PROTOCOL, which suggests that you have faulty hardware or faulty file system drivers.  Again, immediately reopening the file and continuing may just result in another crash.  Worse, it might fatally corrupt the database because the fault in the storage system caused something to overwrite the database file.  Again, the correct thing to do here is not to retry, but instead to report the problem to the user and get them to work the fault then decide for themself whether they want to carry on using the program.

>   2. What is the exhaustive list of error codes that shall be considered
>   as fatal ?

On this page you will see a full list of all error codes:

<https://www.sqlite.org/rescode.html>

Near the top you can see that it lists SQLITE_OK (0), SQLITE_ROW (100), and SQLITE_DONE (101) as the only codes which do not represent errors.  All other codes (including ones you can't find documentation for) are fatal errors which prevent you from working with the database.  So don't test for codes which represent specific errors, instead check for SQLITE_OK and other expected codes then crash for everything else.  This is what good SQLite programs do.

A normal program should just present a useful error message and quit, perhaps something like "Quitting because a SQLite operation returned error 24.".  You might want to generate specific messages for things like a full hard disk but most people don't bother, because there's little chance that the underlying problem is really that the user filled up the disk.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

sanhua.zh
In reply to this post by sanhua.zh
I don’t mean to be rude. BUT, I can’t agree with your opinion, Simon.


1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be treated as fatal errors.
  As an example, SQLITE_BUSY indicates that this op is temporarily failed, but it can be done later. (Note that sometimes you should not retry forever.)
  Another example, while SQLITE_FULL,manually cleaning your pragram cache to make some free space might be a better way than crash your app.


2. Quit while get error is also not a great enough idea. Because not all pragram is a command line tool. It can be a user-oriented application instead of a developer-oriented tool. Users don’t wish to meet a crash.


So, find out how SQLITE_FULL leading to SQLITE_CORRUPT, and fix it or avoid it (if it can’t be fixed) might be the better solution.


If you don’t know or you don’t want to teach us the detail of it, I might try my best to do it. :)


原始邮件
发件人:Simon [hidden email]
收件人:SQLite mailing [hidden email]
发送时间:2016年1月14日(周四) 20:39
主题:Re: [sqlite] Database Corrupt While Disk Full


 On 14 Jan 2016, at 11:55am, Brice André [hidden email] wrote:   I am a little worried with your last post because, I must admint that I do  not take special measures in my application when such errors occur to  guarantee that no more DB access are performed.   I have thus the following questions : If you're writing a proper long-term program, check the result codes returned by every SQLite API call. In most cases all you need to do is check to see that the result is SQLITE_OK. Hope this helps.  1. What would be the proper reaction to SQLITE_FULL, SQLITE_IOERR,  SQLITE_CANTOPEN ? Perform a sqlite3_close ? Just exit the program as is  without touching the database file descriptor ? And once the program has  left, can we perform a sqlite3_open ? At this point there is no need to execute any other sqlite3_ calls. In fact, if you do execute them they'll probably just return another error message. Just print an error message and quit. When the SQLite API is next used to open the file it will know that the file was not closed properly and automatically try to reconstruct an uncorrupted version. This is done without informing the program that anything was wrong. So your question is why should you not try to do this immediately ? The answer is that without the user taking action it's probably going to fail. The original crash might have reported SQLITE_FULL or some other other condition which the user needs to fix before reopening the database. Trying to recover an uncorrupted database while the disk is still full will probably just lead to another crash, so there's no point and, at worst, a possibility of corrupting your database or some other file associated with the program. Another possibility is that the error is something like SQLITE_PROTOCOL, which suggests that you have faulty hardware or faulty file system drivers. Again, immediately reopening the file and continuing may just result in another crash. Worse, it might fatally corrupt the database because the fault in the storage system caused something to overwrite the database file. Again, the correct thing to do here is not to retry, but instead to report the problem to the user and get them to work the fault then decide for themself whether they want to carry on using the program.  2. What is the exhaustive list of error codes that shall be considered  as fatal ? On this page you will see a full list of all error codes: https://www.sqlite.org/rescode.html Near the top you can see that it lists SQLITE_OK (0), SQLITE_ROW (100), and SQLITE_DONE (101) as the only codes which do not represent errors. All other codes (including ones you can't find documentation for) are fatal errors which prevent you from working with the database. So don't test for codes which represent specific errors, instead check for SQLITE_OK and other expected codes then crash for everything else. This is what good SQLite programs do. A normal program should just present a useful error message and quit, perhaps something like "Quitting because a SQLite operation returned error 24.". You might want to generate specific messages for things like a full hard disk but most people don't bother, because there's little chance that the underlying problem is really that the user filled up the disk. Simon. _______________________________________________ sqlite-users mailing list [hidden email] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Stephan Beal-3
On Thu, Jan 14, 2016 at 2:02 PM, sanhua.zh <[hidden email]> wrote:

> I don’t mean to be rude. BUT, I can’t agree with your opinion, Simon.
>
>
> 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be
> treated as fatal errors.
>   As an example, SQLITE_BUSY indicates that this op is temporarily failed,
> but it can be done later. (Note that sometimes you should not retry
> forever.)
>

Simon's fundamentally right, though. The cases you mention here are not
ERROR codes - they're result codes which indicate varying types of success
(or recoverable errors). The errors you ignored early on are not (for most
cases) recoverable errors. If you continue to use an sqlite3 handle after
its API has returned a true error code, you're invoking Undefined Behaviour.

Aside from that, all OSes i've worked with tend to fail in strange ways
when their disks are out of space.

2. Quit while get error is also not a great enough idea.


sqlite has told you "something bad has happened." If you continue, you do
so at your own risk. Weird things happen as various apps and daemons
compete for that last byte of drive space.


> Because not all pragram is a command line tool. It can be a user-oriented
> application instead of a developer-oriented tool. Users don’t wish to meet
> a crash.
>

Pop up a dialog saying, "I/O error!" and _then_ quit. That's better than
the app corrupting their data.


> So, find out how SQLITE_FULL leading to SQLITE_CORRUPT, and fix it or
> avoid it (if it can’t be fixed) might be the better solution.
>

FULL means the drive is full. Most apps can't do much about that. It
generally needs to be resolved by user action - freeing up space.

CORRUPT means sqlite cannot work with it - there is no generic recovery
strategy aside from throwing the DB away and building it anew.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Stephan Beal-3
On Thu, Jan 14, 2016 at 2:09 PM, Stephan Beal <[hidden email]> wrote:

> FULL means the drive is full. Most apps can't do much about that. It
> generally needs to be resolved by user action - freeing up space.
>

Alternately, FULL can mean that the current VFS cannot allocate space, even
though it's underlying storage might have some space. So, in theory, the
VFS (if any) used by your device might be restricting the amount of space
the app can use.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Simon Slavin-3
In reply to this post by sanhua.zh

On 14 Jan 2016, at 1:02pm, sanhua.zh <[hidden email]> wrote:

> I don’t mean to be rude. BUT, I can’t agree with your opinion, Simon.

I will present some arguments on my side.  I hope you take this as cultured conversation and not an outright rejection of your points.

> 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be treated as fatal errors.
>  As an example, SQLITE_BUSY indicates that this op is temporarily failed, but it can be done later. (Note that sometimes you should not retry forever.)

I would say that the programmer should have set an appropriate timeout value:

<https://www.sqlite.org/c3ref/busy_timeout.html>

If you do this then SQLite will handle any temporary problem for you.  If you are still getting SQLITE_BUSY, then I suspect you have a locking problem which cannot be solved inside your program.

>  Another example, while SQLITE_FULL,manually cleaning your pragram cache to make some free space might be a better way than crash your app.

In modern computer use the user is probably running many programs at the same time. So your program cache may be inside your SQLite program, but filling up the disk may cause the user's word processing program to crash and losing important work.  But this will happen without your SQLite program getting any error message.  If you have created a big cache in your program you cannot wait until the SQLite program gets an error message before realising that it is causing problems for your user.

> 2. Quit while get error is also not a great enough idea. Because not all pragram is a command line tool. It can be a user-oriented application instead of a developer-oriented tool. Users don’t wish to meet a crash.

I'm not sure what you expect a user application to do when it cannot continue and will lose any new data typed into it.  What should it do instead of displaying an error message and quitting ?

> So, find out how SQLITE_FULL leading to SQLITE_CORRUPT

SQLITE_FULL is itself a fatal error.  Why are you waiting to get another error message before taking action ?

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

Roger Binns
In reply to this post by sanhua.zh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/01/16 00:44, sanhua.zh wrote:
> Recently, my monitoring system showed that the error code
> SQLITE_FULL and SQLITE_CORRUPT increasing in same trend.

Just as another data point, I had SQLite using code in a library that
was used across a bunch of third party apps, with many millions of
installations on Android, and to a lesser degree on iOS.  (I stored
analytics events in a SQLite database and periodically uploaded them
in batches.)

Although there were Android devices (the really cheap and nasty ones)
that kept running out of space, not once was there corruption.  I was
very careful to use transactions, and pay attention to the return code
of API calls.

SQLite is unlikely to have problems:

  https://sqlite.org/testing.html

> This is happened in iOS. The OS will automatically clean the disk
> cache to make some space while disk free space is low

Android does the same.  One thing you have to be *very* careful about
on iOS (and current Android) is exactly where you place the database
files in your app sandbox.  Most of the directory tree is backed up,
but you don't have direct control over when that happens, or the restore.

If you put the database files in a location that is backed up and
restored, then it is possible for the database and its journal to be
inconsistent with each other.

https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

Using WAL will make you less sensitive to these issues.

Roger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlaXxrQACgkQmOOfHg372QRqzwCfT+Mv9QjLVccydsj0c5wuKq9H
bdIAmQF2BFMzJqXXyxSgvdDeVt8/3j3y
=3tnu
-----END PGP SIGNATURE-----
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

R Smith
In reply to this post by sanhua.zh


On 2016/01/14 3:02 PM, sanhua.zh wrote:
> 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be treated as fatal errors.
>    As an example, SQLITE_BUSY indicates that this op is temporarily failed, but it can be done later. (Note that sometimes you should not retry forever.)
>    Another example, while SQLITE_FULL,manually cleaning your pragram cache to make some free space might be a better way than crash your app.

The error codes (fully error-specific codes, that is) are not
suggestive, they are absolute. If you do not quit immediately, you
should at least stop trying to access the database immediately. If there
was something that could be done about the error, SQLite would have done
it, the error code means SQLite is sure there is nothing that can be
done and so warns you that you should stop and report.

(SQLite_BUSY isn't an error code so much as a status code - if the
situation persists beyond a reasonable time (longer than any of your
transactions might take on a slow device), then it should be regarded as
an error.)


> 2. Quit while get error is also not a great enough idea. Because not all pragram is a command line tool. It can be a user-oriented application instead of a developer-oriented tool. Users don’t wish to meet a crash.

This is very much wrong - when Out-of-memory and out-of-diskspace type
errors are reported, you should immediately halt what you are doing and
release all possible resources soonest. Consider that the user might
have another thing on their system trying to write/read/work, and you
are insisting to occupy some part of it - please don't. Once a user's
system gets to that stage, they need immediate help (if they are not
technical). That situation is long-past the point where you could care
to provide user-niceness. Show a warning/error and die.

If you want to be user-happy-fancy, then check diskspace before you
start any transaction, and keep a record of disk usage during
transactions - when the free space starts shrinking to near the maximum
usage on record, start cleaning your own caches, start showing warnings
/ advise disk-health routines or device-service time.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Database Corrupt While Disk Full

R Smith


On 2016/01/14 6:46 PM, R Smith wrote:
> ...// Out-of-memory and out-of-diskspace type errors are reported//....

Also note here that there is a case where SQLite will report DISK_FULL
errors where the disks are seemingly fine - when you start a transaction
that requires large amounts of space, and your DB file is on a drive
with oodles of space, but the TEMP folder is on a drive that is nearly
full, then the transaction might not complete and report DISK_FULL. (I
understand this can only happen in /some/ journal modes [WAL mode should
be ok for instance], but I am not exactly sure).

This is especially true for running VACUUM on a rather large database. I
myself have my TEMP folder set to a RAM-drive that is only 6GB big, so
trying to VACUUM anything larger than 6GB might fail with DISK_FULL -
for which I usually need to temporarily set another temp folder.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users