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
themaster.
>
> 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