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