Re: setting separate values of replication parameters to each standby to provide more granularity

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: setting separate values of replication parameters to each standby to provide more granularity
Date: 2013-10-01 07:17:00
Message-ID: CABOikdMFe3LSz4CZRAp0eLTjxGDJMvMng=aPV4_wmBJg1rxuvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 26, 2013 at 6:00 PM, Samrat Revagade
<revagade(dot)samrat(at)gmail(dot)com>wrote:

> Hi,
>
> How about providing more granularity to replication, by setting separate
> values of replication parameters to each standby
> for example:
> standby1.wal_sender_timeout= 50s
> standby2.wal_sender_timeout= 40s
>
> The idea is to allow configuration of standby servers such that they have
> there own set of replication parameters as per requirements.
>

How does this interplay with the synchronous_standby_names parameter ? Or
do you think that becomes irrelevant if we do like what you are suggesting
above ? AFAIK synchronous_standby_names was added because we wanted to give
master control on which standbys can become SYNC standbys and in what order
of priority. But if we do what you are suggesting above, I wonder if we can
just have an explicit knob to make a standby a SYNC standby. Say something
like: standby1.sync_mode = SYNC|ASYNC.

The other purpose of synchronous_standby_names is to define order of
preference for sync standbys. Even that can then be explicitly specified
using this mechanism.

I am not sure but may be we can even allow to set synchronous_commit at
each standby level. So depending on the synchronous_commit setting of each
standby and their priorities also explicitly defined by this mechanism,
master will decide which standbys to wait for at the commit time.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-10-01 08:24:41 Re: review: psql and pset without any arguments
Previous Message David Johnston 2013-10-01 04:55:56 Re: Documentation for SET var_name FROM CURRENT