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
> > 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
d. Or may be combination of above, which DBA can use depending on their
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 (email@example.com)
To make changes to your subscription: