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

From: Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: setting separate values of replication parameters to each standby to provide more granularity
Date: 2013-09-26 12:30:19
Message-ID: CAF8Q-GyRXq3TdekaCm477NajePhF6WAx0bz02nF1HjQm9pGdMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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:
http://www.postgresql.org/message-id/CAF8Q-GxVg38M4vvghunTw4nVu69BYfJ5n--QMounC-BWV8r3ow@mail.gmail.com

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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-09-26 12:58:11 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Andres Freund 2013-09-26 11:56:17 Re: Support for REINDEX CONCURRENTLY