On Sun, Jan 26, 2014 at 10:56 PM, Rajeev rastogi <rajeev.rast...@huawei.com> wrote: > 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.
All of those things have been mentioned, but I'm not sure we have consensus on which of them we actually want to do, or how. Figuring that out seems like the next step. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
