From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-09-20 16:23:19 |
Message-ID: | 9454.1316535799@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> I sympathise with this view, to an extent.
> If people want to put all parameters in one file, they can do so. So +1 to that.
> Should they be forced to adopt that new capability by us deliberately
> breaking their existing setups? No. So -1 to that.
> If we do an automatic include of recovery.conf first, then follow by
> reading postgresql,conf then we will preserve the old as well as
> allowing the new.
I don't buy this argument at all. I don't believe that recovery.conf is
part of anyone's automated processes at all, let alone to an extent that
they won't be able to cope with a change to rationalize the file layout.
And most especially I don't buy that someone who does want to keep using
it couldn't cope with adding an "include" to postgresql.conf manually.
If we're going to move these parameters into postgresql.conf, we should
just do that and remove all mention of recovery.conf. Anything else
will generate much more confusion than benefit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-09-20 16:38:47 | Re: unite recovery.conf and postgresql.conf |
Previous Message | Robert Haas | 2011-09-20 16:20:10 | Re: Separating bgwriter and checkpointer |