Re: Proposal for 9.1: WAL streaming from WAL buffers

Florian Pflug wrote:
> glibc defines O_DSYNC as an alias for O_SYNC and warrants that with
> "Most Linux filesystems don't actually implement the POSIX O_SYNC semantics, which require all metadata updates of a
writeto be on disk on returning to userspace, but only the O_DSYNC semantics, which require only actual file data and
metadatanecessary to retrieve it to be on disk by the time the system call returns."
 
>
> If that is true, I believe we should default to open_sync, not fdatasync if open_datasync isn't available, at least
onlinux.
 
>   

It's not true, because Linux O_SYNC semantics are basically that it's 
never worked reliably on ext3.  See 
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php for 
example of how terrible the situation would be if O_SYNC were the 
default on Linux.

We just got a report that a better O_DSYNC is now properly exposed 
starting on kernel 2.6.33+glibc 2.12:  
http://archives.postgresql.org/message-id/201006041539.03868.cousinmarc@gmail.com 
and it's possible they may have finally fixed it so it work like it's 
supposed to.  PostgreSQL versions compiled against the right 
prerequisites will default to O_DSYNC by themselves.  Whether or not 
this is a good thing has yet to be determined.  The last thing we'd want 
to do at this point is make the old and usually broken O_SYNC behavior 
suddenly preferred, when the new and possibly fixed O_DSYNC one will be 
automatically selected when available without any code changes on the 
database side.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us