On 1/15/14, 1:53 PM, Josh Berkus wrote: > I'm particularly thinking about this in relation to the merger of > recovery.conf and postgresql.conf. There are several tools already > (RepMgr, OminPITR, HandyRep, pgPool, etc.) which manage recovery.conf > separately from postgresql.conf. These tools will want to continue > managing recovery.conf as a separate file, even if it's /included in > postgresql.conf now.
That seems like a very general argument. We'd need to consider exactly what these tools want to do, and how that affects the recovery.conf merger. My personal proposal was to allow postgresql.conf to contain recovery parameters, but read recovery.conf last anyway. That would solve that problem. > If conf.d exists by default, and is enabled in postgresql.conf by > default, this is easy: the tool just drops a recovery.conf file into > conf.d. That would just give false hope, I think. My standard operating procedure is to delete the default postgresql.conf and write a new one from scratch (or have deployment tools do it). I don't want to subscribe to a policy that the only endorsed way to maintain postgresql.conf is to start with the default one and edit around carefully. The only way you could achieve your goal is to read the configuration directory automatically, but that would come with its own set of problems. > Yes, I'm also arguing that postgresql.auto.conf should go into conf.d. > I said I'd bring that up again after ALTER SYSTEM SET was committed, and > here it is. Independent of the above, I don't agree with that. postgresql.auto.conf is a special thing and should have its own special place. For once thing, when putting configuration files in a separate directory structure (/etc/ vs /var), then postgresql.auto.conf should stay in the data directory. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
