The Linux fsync man page says:
"It does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync on the file descriptor of the directory is also needed."
AFAIK, we don't care about it at the moment. The actual behaviour depends on the filesystem, reiserfs and other journaling filesystems probably don't need the explicit fsync on the parent directory, but at least ext2 does.
I've experimented with a user-mode-linux installation, crashing it at specific points. It seems that on ext2, it's possible to get the database in non-consistent state.
Especially:
1. start transaction 2. do a lot of updates, so that a new xlog file is created 3. commit 4. crash
Sometimes the creation of the new xlog file is lost, losing the already committed transaction.
I also got into this situation after one crash test:
template1=# SELECT * FROM foo;
ERROR: could not access status of transaction 1768515945
DETAIL: could not open file "/home/hlinnaka/pgsql/data_broken/pg_clog/0696": No such file or directory
I haven't tried to debug it more deeply.
Should we fix this by fsyncing the parent directory of new files? We could also declare ext2 broken, but there could be others.
- Heikki
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
