Thread: fsync vs fdatasync

Is there any reason to EVER call pg_fsync?

What would happen if we always called pg_fdatasync?

Just curious, is there a reason why we would always want the meta data updated
for each block update? Does postgres use it? Wouldn't the replacement of fsync
with fdatasync increase performance on all platforms which support the
difference?

Are there any reasons not to?

On Sun, 10 Jun 2001, mlw wrote:

> Is there any reason to EVER call pg_fsync?
>
> What would happen if we always called pg_fdatasync?

In theory, nothing.  I believe SUS guarantees that fdatasync
will flush all data and metadata to disk, _except_ perhaps
inode access/change/modify times.  This means file size,
permissions, ownership and indirect blocks (or whatever is
relevant to your filesystem).

Thus, unless you need the timestamps to be accurate, it is
always safe.

Unfortunately, there are (said to be -- I couldn't name one)
implementations which predate this (fairly sane) semantic,
and flush only file contents.

I think that use of fsync is wise on occasion.  If we know
that (for example) we've extended the file, then fdatasync
will behave as fsync on SUS-conformant platforms, and will
risk data loss on non-conformant platforms.

Matthew.

mlw <markw@mohawksoft.com> writes:
> Wouldn't the replacement of fsync with fdatasync increase performance
> on all platforms which support the difference?

We already prefer fdatasync where available, in performance-critical
pathways.
        regards, tom lane