setting separate values of replication parameters to each standby to provide more granularity - Mailing list pgsql-hackers

From Samrat Revagade
Subject setting separate values of replication parameters to each standby to provide more granularity
Date
Msg-id CAF8Q-GyRXq3TdekaCm477NajePhF6WAx0bz02nF1HjQm9pGdMw@mail.gmail.com
Whole thread Raw
Responses Re: setting separate values of replication parameters to each standby to provide more granularity
List pgsql-hackers
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.
If they are not specified then configure standby with default settings.

I have already raised this point when I made proposal about introducing the ini file, but there was no feedback on this point (setting separate values to each standby) here is the link for that:

As per discussion use of ini file is not necessary. Currently PostgreSQL provides infrastructure which allows level-2 nesting 
( If we need further nesting of parameters we can use Andres patch  http://www.postgresql.org/message-id/20130225211533.GD3849@awork2.anarazel.de)
we can do setting as follows: 
----------postgresql.conf--------------
st1.wal_sender_timeout = 40s
st2.wal_sender_timeout = 50s
-------------------------------------------
postgres=# show st1.wal_sender_timeout ;
 st1.wal_sender_timeout
------------------------
 40s
(1 row)

postgres=# show st2.wal_sender_timeout ; 
 st2.wal_sender_timeout
------------------------
 50s
(1 row)

But this just handles the parser stage, we need to write the underlying code which actually configures standby server with corresponding parameter values.

I think that use of postgresql.conf is much better option to do this.
one can easily do argument about the size and complexity of postgresql.conf if it allows such setting.
In that case we can use *include* directive and separate out replication parameters to another sub file.
But after all of this, I think it will be a good change and will provide more granularity to the replication.

Greetings, 
Samrat Revagade, 
NTT DATA OSS Center Pune, India.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: "Etsuro Fujita"
Date:
Subject: Re: Patch for fast gin cache performance improvement