On 11/27/15 8:18 AM, Michael Paquier wrote: > On Fri, Nov 27, 2015 at 8:17 PM, Tomas Vondra > <tomas.von...@2ndquadrant.com> wrote: >> > So, what's going on? The problem is that while the rename() is atomic, it's >> > not guaranteed to be durable without an explicit fsync on the parent >> > directory. And by default we only do fdatasync on the recycled segments, >> > which may not force fsync on the directory (and ext4 does not do that, >> > apparently). > Yeah, that seems to be the way the POSIX spec clears things. > "If _POSIX_SYNCHRONIZED_IO is defined, the fsync() function shall > force all currently queued I/O operations associated with the file > indicated by file descriptor fildes to the synchronized I/O completion > state. All I/O operations shall be completed as defined for > synchronized I/O file integrity completion." > http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html > If I understand that right, it is guaranteed that the rename() will be > atomic, meaning that there will be only one file even if there is a > crash, but that we need to fsync() the parent directory as mentioned.
I don't see anywhere in the spec that a rename needs an fsync of the directory to be durable. I can see why that would be needed in practice, though. File system developers would probably be able to give a more definite answer. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
