On 19/09/14 17:40, Bokassa wrote: > Hi all, > I see my query hanging with this stack: > > dybagme->where > #0 0x000000332b00ee00 in __fsync_nocancel () from /lib64/libpthread.so.0 > #1 0x000000000041b418 in full_fsync (fd=6, fullSync=0, dataOnly=0) at > sqlite3.c:27735 ... > The program itself is in state D waiting for IO. I am writing on a local > disk. I don't use threads. > What can be wrong?
SQLite isn't wrong. It uses the fsync api provided by Unix to ensure file/directory contents are written to the storage media (ie would still be there after a power failure). You'll need to look in your OS logs and monitoring tools to find out what is going on. Note that some filesystems are implemented such that asking to fsync a file instead does a sync of the whole filesystem (it is done because of metadata and journalling issues). For example if you were separately extracting lots of files they could get caught up in the fsync. The spec for fsync is that it doesn't return until the file/directory is on storage. Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
