Re: unite recovery.conf and postgresql.conf
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: josh@agliodbs.com, pgsql-hackers@postgresql.org
Date: 2011-09-24T16:42:54Z
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
On Fri, Sep 23, 2011 at 6:55 PM, Tatsuo Ishii <ishii@postgresql.org> wrote: >>> There are many. Tools I can name include pgpool, 2warm, PITRtools, but >>> there are also various tools from Sun, an IBM reseller I have >>> forgotten the name of, OmniTI and various other backup software >>> providers. Those are just the ones I can recall quickly. We've >>> encouraged people to write software on top and they have done so. >> >> Actually, just to correct this list: >> * there are no tools from Sun >> * pgPool2 does not deal with recovery.conf > > I'm not sure what you mean by "not deal with" but part of pgpool-II's > functionality assumes that we can easily generate recovery.conf. If > reconf.conf is integrated into postgresql.conf, we need to edit > postgresql.conf, which is a little bit harder than generating > recovery.conf, I think. Since we haven't yet come up with a reasonable way of machine-editing postgresql.conf, this seems like a fairly serious objection to getting rid of recovery.conf. I wonder if there's a way we can work around that... *thinks a little* What if we modified pg_ctl to allow passing configuration parameters through to postmaster, so you could do something like this: pg_ctl start -c work_mem=8MB -c recovery_target_time='...' Would that meet pgpool's needs? (Sadly pg_ctl -c means something else right now, so we'd probably have to pick another option name, but you get the idea.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company