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