On Fri, Jan 10, 2014 at 9:17 PM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Jan 10, 2014 at 10:21:42AM +0530, Amit Kapila wrote: >> Here I think if user is aware from beginning that this is the behaviour, >> then may be the importance of message is not very high. >> What I want to say is that if we provide a UI in such a way that user >> decides during setup of server the behavior that is required by him. >> >> For example, if we provide a new parameter >> available_synchronous_standby_names along with current parameter >> and ask user to use this new parameter, if he wishes to synchronously >> commit transactions on another server when it is available, else it will >> operate as a standalone sync master. > > I know there was a desire to remove this TODO item, but I think we have > brought up enough new issues that we can keep it to see if we can come > up with a solution.
I am not telling any such thing, rather I am suggesting some other way for this new mode. > I have added a link to this discussion on the TODO > item. > > I think we will need at least four new GUC variables: > > * timeout control for degraded mode > * command to run during switch to degraded mode > * command to run during switch from degraded mode > * read-only variable to report degraded mode Okay, this is one way of providing this new mode, others could be: a. Have just one GUC sync_standalone_mode = true|false and make this as PGC_POSTMASTER parameter, so that user is only allowed to set this mode at startup. Even if we don't want it as Postmaster parameter, we can mention to users that they can change this parameter only before server reaches current situation. I understand that without any alarm or some other way, it is difficult for user to know and change it, but I think in that case he should set it before server startup. b. On above lines, instead of boolean parameter, provide a parameter similar to current one such as available_synchronous_standby_names, setting of this should follow what I said in point a. The benefit in this as compare to 'a' is that it appears to be more like what we currently have. I think if we try to solve this problem by providing a way so that user can change it at runtime or when the problem actually occurred, it can make the UI more complex and difficult for us to provide a way so that user can be alerted on such situation. We can keep our options open so that if tomorrow, we can find any reasonable way, then we can provide it to user a mechanism for changing this at runtime, but I don't think it is stopping us from providing a way with which user can get the benefit of this mode by providing start time parameter. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
