On Jun 12, 2010, at 3:10 , Josh Berkus wrote:
>> Hm, but then Robert's failure case is real, and streaming replication might break due to an OS-level crash of the
master.Or am I missing something?
>
> 1) Master goes out
> 2) "floating" transaction applied to standby.
> 3) Standby goes out
> 4) Power back on
> 5) master comes up
> 6) standby comes up
>
> It seems like, in that sequence, the standby would have one transaction
> which the master doesn't have, yet the standby thinks it can continue
> getting WAL from the master. Or did I miss something which makes this
> impossible?
I did indeed miss something - with wal_sync_method set to either open_datasync or open_sync, all written WAL is also
synced.Since open_datasync is the preferred setting according to
http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#GUC-WAL-SYNC-METHOD,systems supporting open_datasync
shouldbe safe.
My Ubuntu 10.04 box running postgres 8.4.4 doesn't support open_datasync though, and hence defaults to fdatasync.
Probablybecause of this fragment in xlogdefs.h
#if O_DSYNC != BARE_OPEN_SYNC_FLAG
#define OPEN_DATASYNC_FLAG (O_DSYNC | PG_O_DIRECT)
#endif
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 on
linux.
best regards,
Florian Pflug