On 01/25/2014, Josh Berkus wrote: > > ISTM the consensus is that we need better monitoring/administration > > interfaces so that people can script the behavior they want in > > external tools. Also, a new synchronous apply replication mode would > > be handy, but that'd be a whole different patch. We don't have a > patch > > on the table that we could consider committing any time soon, so I'm > > going to mark this as rejected in the commitfest app. > > I don't feel that "we'll never do auto-degrade" is determinative; > several hackers were for auto-degrade, and they have a good use-case > argument. However, we do have consensus that we need more scaffolding > than this patch supplies in order to make auto-degrade *safe*. > > I encourage the submitter to resumbit and improved version of this > patch (one with more monitorability) for 9.5 CF1. That'll give us a > whole dev cycle to argue about it.
I shall rework to improve this patch. Below are the summarization of all discussions, which will be used as input for improving the patch: 1. Method of degrading the synchronous mode: a. Expose the configuration variable to a new SQL-callable functions. b. Using ALTER SYSTEM SET. c. Auto-degrade using some sort of configuration parameter as done in current patch. d. Or may be combination of above, which DBA can use depending on their use-cases. We can discuss further to decide on one of the approach. 2. Synchronous mode should upgraded/restored after at-least one synchronous standby comes up and has caught up with the master. 3. A better monitoring/administration interfaces, which can be even better if it is made as a generic trap system. I shall propose a better approach for this. 4. Send committing clients, a WARNING if they have committed a synchronous transaction and we are in degraded mode. 5. Please add more if I am missing something. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers