First of all, my English skill is not good. So please forgive me if my
sentences are rude.
My name is Byungeun Park.I am a Computer Science Master student in South
Korea. I'm doing a
research to enhance the SQLite performance.
=========================================================
static int unixSync(sqlite3_file *id, int flags){
int rc;
unixFile *pFile = (unixFile*)id;
int isDataOnly = (flags&SQLITE_SYNC_DATAONLY);
int isFullsync = (flags&0x0F)==SQLITE_SYNC_FULL;
/* Check that one of SQLITE_SYNC_NORMAL or FULL was passed */
assert((flags&0x0F)==SQLITE_SYNC_NORMAL
|| (flags&0x0F)==SQLITE_SYNC_FULL
);
/* Unix cannot, but some systems may return SQLITE_FULL from here. This
** line is to test that doing so does not cause any problems.
*/
SimulateDiskfullError( return SQLITE_FULL );
assert( pFile );
OSTRACE(("SYNC %-3d\n", pFile->h));
rc = full_fsync(pFile->h, isFullsync, isDataOnly);
SimulateIOError( rc=1 );
if( rc ){
storeLastErrno(pFile, errno);
return unixLogError(SQLITE_IOERR_FSYNC, "full_fsync", pFile->zPath);
}
/* Also fsync the directory containing the file if the DIRSYNC flag
** is set. This is a one-time occurrence. Many systems (examples: AIX)
** are unable to fsync a directory, so ignore errors on the fsync.
*/
if( pFile->ctrlFlags & UNIXFILE_DIRSYNC ){
int dirfd;
OSTRACE(("DIRSYNC %s (have_fullfsync=%d fullsync=%d)\n", pFile->zPath,
HAVE_FULLFSYNC, isFullsync));
rc = osOpenDirectory(pFile->zPath, &dirfd);
if( rc==SQLITE_OK ){
full_fsync(dirfd, 0, 0);
robust_close(pFile, dirfd, __LINE__);
}else{
assert( rc==SQLITE_CANTOPEN );
rc = SQLITE_OK;
}
pFile->ctrlFlags &= ~UNIXFILE_DIRSYNC;
}
return rc;
}
=========================================================
In PERSIST mode, journal is still remain. But the red code is always
generated in each transaction. That is, journal file descriptor is always
closed at the end of transaction and reopen at the start of next
transaction(I think this is a bug).
=========================================================
rc = sqlite3_open("test.db", &db);
if( rc ){
fprintf(stderr, "Can't open db: %s\n", sqlite3_errmsg(db));
sqlite3_close(db);
return(1);
}
sqlite3_exec(db, "PRAGMA journal_mode=PERSIST", NULL, NULL, &zErrMsg);
for(i=0;i<100;i++){
sprintf(buf1, "insert into t1 values(%d, 't1-data-%d')", i, i);
sqlite3_exec(db, buf1, NULL, 0, &zErrMsg);
}
sqlite3_close(db);
=========================================================
This is the part of my test file. This code insert 0 to 100 values in the
table t1 with PERSIST mode. Until the "test.db" closed, each insert
statement open&close the journal file descriptor(each insert command pass
through the red code).
>From the red code documentation, the code is one time occurrence for fsync
directory. I am not sure if this one time occurrence means one time per one
transaction(one insert command) or one time until test.db close.
*I think one time journal directory sync and no close journal file
descriptor until the test.db close is enough.*
Even though there is an accident like power disconnection, sqlite code can
recognize the directory information loss and reopen the database file and
the journal file. I get this result after I remove the red code and run
with this test code in Linux. I supposed ctrl + c during program running is
transaction interruption. After interruption and rerun the program, I
checked the database can call the table t1 contents by select statement.
Do you think sync journal's directory per transaction is correct?
If this opinion is wrong, would you mind if I know why
1. the directory must sync per transaction?
2. PERSIST mode must close the journal file descriptor?
Thanks
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
