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.
UsingALTER SYSTEM SET.c. Auto-degrade using some sort of configuration parameter as done in current patch.d. Or may be
combinationof 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