Re: recovery.conf location

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: recovery.conf location
Date: 2010-09-27 07:55:32
Message-ID: 4CA04DF4.3070203@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/27/2010 10:08 AM, Robert Haas wrote:
> The thing about the parameters for synchronous replication that is a
> little different is that you need a whole set of parameters *for each
> standby*. There's not a terribly clean way to handle that in
> postgresql.conf as it exists today, but getting any agreement on
> non-trivial changes to postgresql.conf has proven to be next to
> impossible, despite the fact that AFAICT approximately no one is happy
> with the status quo.

Huh? Since when? I thought the whole "standby registration on the
master" discussion was still ongoing. And if we don't have a clean
format to do that in postgresql.conf, we don't have one anywhere else,
either.

As far as each standby is concerned, there's absolutely no reason not to
have all the standby parameters in postgresql.conf. The one and only
thing we'd need to deal with is how the standby writes a bit to indicate
that it has failed over and is no longer a standby ... probably the
simplest idea is to simply leave the trigger file in place.

I am opposed to any solution to configuring sync rep which involves
PostgreSQL having multiple configuration files in multiple different
formats. All of our configuration files should be in the exact same
format, and ideally there should only be one configuration file. There
is no DBA or sysadmin on Earth who would appreciate having to edit one
file in param=val format, and a second file in JSON or XML.

A good compromise with historical formats is to use Apache HTTPD's
approach, which supports both simple param=val declarations, and also
simple blocks. Assuming we need to configure the standbys on the master
at all, which has not yet been decided on this list AFAIK.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2010-09-27 08:01:33 Re: bg worker: general purpose requirements
Previous Message Itagaki Takahiro 2010-09-27 07:54:32 Re: TODO: You can alter it, but you can't view it