On 01/26/2014 07:56 PM, Rajeev rastogi wrote: > 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.
I think we actually need two degrade modes: A. degrade once: if the sync standby connection is ever lost, degrade and do not resync. B. reconnect: if the sync standby catches up again, return it to sync status. The reason you'd want "degrade once" is to avoid the "flaky network" issue where you're constantly degrading then reattaching the sync standby, resulting in horrible performance. If we did offer "degrade once" though, we'd need some easy way to determine that the master was in a state of permanent degrade, and a command to make it resync. Discuss? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
