On Mon, Jul 22, 2013 at 10:59 PM, Greg Stark st...@mit.edu wrote:
On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
revagade.sam...@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
On Fri, Jul 19, 2013 at 6:53 PM, Andres Freund and...@2ndquadrant.com wrote:
So you can just do stuff like:
server.foo.grand_unified_config = value.
it looks good to me too. when server parse values which is written in
postgresql.conf, server handles those parameter as item list value.
after
On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
revagade.sam...@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
Hi,
I was going through the archives and there was a discussion about
using ini file to setup
replication.(http://www.postgresql.org/message-id/4c9876b4.9020...@enterprisedb.com).
I think if we work on this proposal and separate out the replication
setup from postgresql.conf file then we can
Please find updated hyperlinks:
Below I have explained how to to use ini file for failback safe stadby setup:
While discussing feature of fail-back safe standby
(CAF8Q-Gy7xa60HwXc0MKajjkWFEbFDWTG=ggyu1kmt+s2xcq...@mail.gmail.com)
On 2013-07-19 14:54:16 +0530, Samrat Revagade wrote:
I was going through the archives and there was a discussion about
using ini file to setup
replication.(http://www.postgresql.org/message-id/4c9876b4.9020...@enterprisedb.com).
I think if we work on this proposal and separate out the
*for example: for failback safe standby.*
I think that introducing another configuration format is a pretty bad
idea. While something new might not turn out to be as bad, we've seen
how annoying a separate configuration format turned out for
recovery.conf.
Its not totally different way of
I've even proposed that in the past in
20130225211533.gd3...@awork2.anarazel.de . I plan to propose an updated
version of that patch (not allowing numeric 2nd level ids) for the next
CF.
So you can just do stuff like:
server.foo.grand_unified_config = value.
Sounds good to me. I can