On Mon, Jul 22, 2013 at 10:59 PM, Greg Stark <stark@mit.edu> wrote:
> On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
> <revagade.samrat@gmail.com> wrote:
>
>> for example:
>> if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12
>> setting's for particular server will be:
>>
>> considering the way of setting value to conf parameters : guc . value
>>
>> standby_name.'AAA'
>> synchronous_transfer. commit
>> wal_sender_timeout.60
>
>
> I have a feeling Samrat and Sawada-san have some good use cases where
> this extra syntax could be a big step up in expressiveness. But I'm
> having a hard time figuring out exactly what they have in mind. If
> either of you could explain in more detail how the extra syntax would
> apply to your use case and how it would let you do something that you
> can't already do it might be helpful.
>
> I'm assuming the idea is something like having a single config file
> which can work for the server regardless of whether it's acting as the
> primary or standby and then be able to switch roles by switching a
> single flag which would control which parts of the config file were
> applied. But I'm having a hard time seeing how exactly that would
> work.
in this approach which GUC parameters is written in postgresql.conf,
user would write many extra line in postgresql.conf by a standby
server as Samrat suggested. It will increase size of postgresql.conf.
I think it is not good that all those parameters are written in
postgresql.conf.
that is, I think that those parameters should be written in separately
file. e.g., we can set separately any parameter using "include" (or
"include if exist") in postgresql.conf.
if include file doesn't exist, we would set default value to each wal
sender. that is, we give up ini file, and we provide mechanism of
setting to each wal sender as option of overwrite.
of course to support this approach, it needs to use the patch which
Andres suggested, and server should be able to handle toke which is
two or mote separated by a dot. so we would like to help this
approach.
Regards,
----
Sawada Masahiko