Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id CABUevEy5aWuwySXEC6i3JA6cvy8agGZHQbOn0RVZ4h4oxM0Dkw@mail.gmail.com
Whole thread Raw
In response to unite recovery.conf and postgresql.conf  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: unite recovery.conf and postgresql.conf
List pgsql-hackers
On Fri, Sep 9, 2011 at 11:56, Fujii Masao <masao.fujii@gmail.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/


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: unite recovery.conf and postgresql.conf
Next
From: Magnus Hagander
Date:
Subject: Re: WAL "low watermark" during base backup