Skip site navigation (1) Skip section navigation (2)

Re: unite recovery.conf and postgresql.conf

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: unite recovery.conf and postgresql.conf
Date: 2011-09-24 16:42:54
Message-ID: CA+Tgmoa-hK8Gi1RSevbL_LtCUn8RuKh1_YowHQ8p3WLwVz1JoQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Sep 23, 2011 at 6:55 PM, Tatsuo Ishii <ishii(at)postgresql(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-09-24 16:46:48
Subject: Re: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Previous:From: Andres FreundDate: 2011-09-24 16:26:10
Subject: Re: posix_fadvsise in base backups

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group