Re: Standalone synchronous master - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Standalone synchronous master
Date
Msg-id CAA4eK1K8CwnsH59ofm+spErd7Tthi=uZ_RSgw+VTkO9yRtMqBA@mail.gmail.com
Whole thread Raw
In response to Standalone synchronous master  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Responses Re: Standalone synchronous master
List pgsql-hackers
On Wed, Nov 13, 2013 at 6:39 PM, Rajeev rastogi
<rajeev.rastogi@huawei.com> wrote:

> Add a new "eager" synchronous mode that starts out synchronous but reverts
> to asynchronous after a failure timeout period
>
> This would require some type of command to be executed to alert
> administrators of this change.
>
> http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php
> This patch implementation is in the same line as it was given in the earlier
> thread.
>
> Some Of the additional important changes are:
>
> 1.       Have added two GUC variable to take commands from user to be
> executed
>
> a.       Master_to_standalone_cmd: To be executed before master switches to
> standalone mode.
>
> b.      Master_to_sync_cmd: To be executed before master switches from sync
> mode to standalone mode.
  In description of both switches (a & b), you are telling that it
will switch to  standalone mode, I think by your point 1b. you mean to say other way  (switch from standalone to sync
mode).
  Instead of getting commands, why can't we just log such actions? I think  adding 3 new guc variables for this
functionalityseems to be bit high.
 
  Also what will happen when it switches to standalone mode incase there  are some async standby's already connected to
itbefore going to  standalone mode, if it continues to send data then I think naming it as  'enable_standalone_master'
isnot good.
 


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Next
From: Greg Stark
Date:
Subject: Re: Bug in visibility map WAL-logging