Re: Standalone synchronous master

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