On Tue, Aug 21, 2012 at 5:30 AM, Dominique Pellé
<dominique.pe...@gmail.com>wrote:

> Hi
>
> Once in a while, I see an error when doing a "VACUUM" operation.
>
> sqlite3_exec3(...) returns status=14 (unable to open database file).
> I suppose that it fails to open a temporary database when doing
> the VACUUM operation, but I don't see why.
>

You might have plenty of disk space left, but do you have plenty of *temp*
disk space left?  I assume you are on Linux?  Is /var/tmp mounted on a
separate filesystem?  Do you have plenty of disk space in /var/tmp?


>
> sqlite3_extended_errcode(db) also returns extendedErrorCode=14
>
> The code to vacuum looks simple, it does these operations:
>
> ==========================================================
> sqlite3* db;
> int status = sqlite3_open(dbName, &db);
> if (status != SQLITE_OK) {
>   ...  no error happening here.
> }
>
> char* errMsg = NULL;
> status = sqlite3_exec(db, "PRAGMA synchronous=OFF;", NULL, NULL, &errMsg);
> if (status != SQLITE_OK) {
>   ... no error happening here.
> }
>
> status = sqlite3_exec(db, "VACUUM;", NULL, NULL, &errMsg);
> if (status != SQLITE_OK) {
>    ... and here I get status is 14 once in a while?!
> }
>
> status = sqlite3_close(db);
> if (status != SQLITE_OK) {
>    ... no error happening here, even when above VACUUM failed.
> }
> ==========================================================
>
> I precise that:
>
> - It's doing VACUUM of fairly large DBs (1 or a couple of Gb in general)
>   but the file system has far more free space.  I realize that
>   VACUUM needs free space (>= 2 or 3 times the size of the DB?)
>   That should not be the problem. And if it was, I would expect
>   a different error code than 14.
>
> - I'm doing several VACUUM in parallel of different DBs
>   in different processes. I'm not using threads.
>   Each process VACUUM a different database which is simple.
>
> - The DB is opened just before doing the VACUUM (as in above code)
>   There is no other opened connection to it.
>
> - It's not 100% reproducible. It happens maybe 1/10
>   of the times, which suggests that it could be a race condition.
>   Yet it's not using threads. Different processes uses
>   different databases, so it does not seem possible to have
>   race conditions in those conditions.
>
> - Even though VACUUM fails, the DB looks fine.
>
> - It's using SQLite-3.7.3  (actually, Spatialite-2.4.0) on Linux x86_64.
>   (OK, maybe time to upgrade SQLite)
>
> - I've checked with Valgrind memory checker on tiny
>   databases: it sees no problem.
>
> -> Any idea what could be wrong?
>
> I wonder whether VACUUM of different databases happening
> in parallel in different processes could use the same temporary
> file names, causing conflicts.
>
> Regards
> -- Dominique
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to