Skip site navigation (1) Skip section navigation (2)

Re: unite recovery.conf and postgresql.conf

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-09-09 10:21:00
Message-ID: CABUevEy5aWuwySXEC6i3JA6cvy8agGZHQbOn0RVZ4h4oxM0Dkw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Sep 9, 2011 at 11:56, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> Hi,
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>
> In previous discussion, we've reached the consensus that we should unite
> recovery.conf and postgresql.conf. The attached patch does that. The
> patch is WIP, I'll have to update the document, but if you notice something,
> please feel free to comment.
>
> This patch allows us to specify recovery parameters like primary_conninfo
> in postgresql.conf. You can change some of them without restarting
> the server (i.e., by using "pg_ctl reload") and see the current settings by
> SHOW command. But note that recovery.conf is still required as a status
> file for archive recovery and standby server even if you put all the settings
> in postgresql.conf. Recovery parameters in postgresql.conf only have effect
> when recovery.conf exists.

Why exactly do we need to keep recovery.conf in this case?


> For backward compatibility, this patch still allows us to specify recovery
> parameters in recovery.conf. But, as in past years, you cannot reload
> recovery.conf and see the current settings by SHOW command. We should
> recommend to put all the settings in postgresql.conf and empty recovery.conf,
> but you can also put all recovery parameters in recovery.conf.

Perhaps we should just have people use recovery.conf as an include
file in this case?

As a whole, I'm not sure I like the idea of having such critical
parameters in two different places. Do we really need to care about
the backwards compatibility of something like that this much?


> If the same parameter is specified in both file, the setting in recovery.conf
> overrides that in postgresql.conf. In this case, SHOW command displays
> the settings in postgresql.conf even though they are not used at all. Even if

Now, *that* is just broken, IMHO. The SHOW command should show what is
actually in use, period. Everything is guaranteed to confuse the hell
out of anybody trying to use it.


> you change the settings in postgresql.conf and reload it, they have no effect
> because the settings in recovery.conf are used preferentially.
>
> These limitations on recovery.conf might confuse users. But since most
> users will put all the settings in postgresql.conf if we recommend to do that,
> I don't think that it's worth complicating the source code for getting rid of
> those limitations.

I think we should just get rid of supporting them in recovery.conf
completely. Recovery settings are critical, and making that confusing
to the user is not a good thing.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-09-09 10:28:18
Subject: Re: WAL "low watermark" during base backup
Previous:From: Fujii MasaoDate: 2011-09-09 09:56:09
Subject: unite recovery.conf and postgresql.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group