Re: unite recovery.conf and postgresql.conf

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>

To: Fujii Masao <masao.fujii@gmail.com>

Cc: Peter Eisentraut <peter_e@gmx.net>, Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2011-09-15T08:44:46Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Restructure error handling in reading of postgresql.conf.
- d56b3afc0376 9.2.0 cited

Fujii Masao <masao.fujii@gmail.com> writes:
> If we'd like to treat recovery.conf as if it's under the data directory, I'm
> afraid that we should add complicated code to parse recovery.conf after
> the value of data_directory has been determined from postgresql.conf.
> Furthermore, what if recovery.conf has another setting of data_directory?

We already do this dance for custom_variable_classes.  IIRC the only
thing you have to care about is setting the GUC before any other one.  I
guess you could just process the data_directory the same way, before the
main loop, and be done with it.

> Since recovery.conf is a configuration file, it's intuitive for me to put it
> in configuration file directory rather than data directory. So I'm not inclined
> to treat recovery.conf as if it's under data directory. Is this OK?

I think that if we keep some compatibility with recovery.conf, then we
need to include finding it in the data_directory or the configuration
file directory, in that order, and with a LOG message that says where we
did find it.

I think we should *NOT* load both of them with some priority rules.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support