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

Поиск
Список
Период
Сортировка
От Samrat Revagade
Тема setting separate values of replication parameters to each standby to provide more granularity
Дата
Msg-id CAF8Q-GyRXq3TdekaCm477NajePhF6WAx0bz02nF1HjQm9pGdMw@mail.gmail.com
обсуждение исходный текст
Ответы Re: setting separate values of replication parameters to each standby to provide more granularity  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: "Etsuro Fujita"
Дата:
Сообщение: Re: Patch for fast gin cache performance improvement