From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-15 08:44:46 |
Message-ID: | 87sjnymby9.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-09-15 08:52:53 | Re: [REVIEW] pg_last_xact_insert_timestamp |
Previous Message | Yeb Havinga | 2011-09-15 08:18:12 | Patch for cursor calling with named parameters |