On Thu, Sep 19, 2013 at 4:02 PM, Fujii Masao <masao.fu...@gmail.com> wrote:
> > > Hmm... when synchronous_transfer is set to data_flush, > IMO the intuitive behaviors are > > (1) synchronous_commit = on > A data flush should wait for the corresponding WAL to be > flushed in the standby > > (2) synchronous_commit = remote_write > A data flush should wait for the corresponding WAL to be > written to OS in the standby. > > (3) synchronous_commit = local > (4) synchronous_commit = off > A data flush should wait for the corresponding WAL to be > written locally in the master. > I thought synchronous_commit and synchronous_transfer are kind of orthogonal to each other. synchronous_commit only controls whether and how to wait for the standby only when a transaction commits. synchronous_transfer OTOH tells how to interpret the standby listed in synchronous_standbys parameter. If set to "commit" then they are synchronous standbys (like today). If set to "data_flush", they are asynchronous failback safe standby and if set to "all" then they are synchronous failback safe standbys. Well, its confusing :-( So IMHO in the current state of things, the synchronous_transfer GUC can not be changed at a session/transaction level since all backends, including background workers must honor the settings to guarantee failback safety. synchronous_commit still works the same way, but is ignored if synchronous_transfer is set to "data_flush" because that effectively tells us that the standbys listed under synchronous_standbys are really *async* standbys with failback safety. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee
