On Fri, Sep 27, 2013 at 5:18 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > On Fri, Sep 27, 2013 at 1:28 PM, Sawada Masahiko <sawada.m...@gmail.com> > wrote: >> >> >> > >> >> 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? >> > > No, user can still override the transaction commit point wait. So if > > synchronous_transfer is set to "all": > - If synchronous_commit is ON - wait at all points > - If synchronous_commit is OFF - wait only at buffer flush (and other > related to failback safety) points > > synchronous_transfer is set to "data_flush": > - If synchronous_commit is either ON o OFF - do not wait at commit points, > but wait at all other points > > synchronous_transfer is set to "commit": > - If synchronous_commit is ON - wait at commit point > - If synchronous_commit is OFF - do not wait at any point >
Thank you for explain. Understood. if synchronous_transfer is set 'all' and user changes synchronous_commit to 'off'( or 'local') at a transaction, the master server wait at buffer flush, but doesn't wait at commit points. Right? In currently patch, synchronous_transfer works in cooperation with synchronous_commit. But if user changes synchronous_commit at a transaction, they are not in cooperation. So, your idea might be better than currently behaviour of synchronous_transfer. 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
