On Thu, Sep 26, 2013 at 8:54 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > 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. >
Thank you for comment. I think it is good simple idea. In your opinion, if synchronous_transfer is set 'all' and synchronous_commit is set 'on', the master wait for data flush eve if user sets synchronous_commit to 'local' or 'off'. For example, when user want to do transaction early, user can't do this. we leave the such situation as constraint? Regards, ------- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers