On Tue, Aug 21, 2012 at 5:30 AM, Dominique Pellé
<[email protected]>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
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
D. Richard Hipp
[email protected]
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
