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
