1. the directory must sync per transaction?
Directory synchronization is necessary.
For example, If current file system uses EXT3 or EXT4 on linux, files can be
lost if directory sync is not called.
AFAIK, new created journal file may not be linked at that time.
To get more detailed information about that, you may need to investigate about
linux file system.
2. PERSIST mode must close the journal file descriptor?
Sorry, I don’t know exactly about this question. :)
In my guess, multiple connections to same sqlite database file can use
different rollback journal mode.
(Ex: connection 1 uses delete mode and connection 2 uses persist mode)
To make it possible, SQLite may close journal file for each end of transaction.
(I think it is not a correct answer, sorry.)
Regards,
Yongil
> 2016. 6. 16., 오후 7:28, 박병언 <byungeunk...@gmail.com> 작성:
>
> 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
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
