Re: unite recovery.conf and postgresql.conf

On 12/14/2011 04:57 PM, Josh Berkus wrote:
> How will things work for PITR?

Left that out mainly because I was already running too long there, but I
do think there's a reasonable path. There is one additional wrinkle in
there to consider that I've thought of so far, falling into the "what is
the best UI for this?" category I think.

Put the stuff you used to insert into recovery.conf into postgresql.conf
instead. If you don't like that, use another file and include it with
one of the multiple options for that--same migration option I already
suggested. Run "pg_ctl recovery"; under the hood that's actually
creating standby.enabled instead of recovery.conf, but you don't have to
know that. You'd suggested renaming it to reflect its most common usage
now, and I thought that was quite sensible. It helps with the "things
have changed, please drive carefully" feel too.

It seems possible to have two files for state kickoff/tracking here
instead, maybe have recovery.enabled and standby.enabled. Is that extra
complexity a useful thing? I haven't dug into that new topic much yet.
(Look at that! I think I just found a *new* topic here!)

There are some questions around what to do when it's done. The new
proposed behavior is to delete the standby.enabled file. But that
doesn't remove the changes made for recovery like the old recovery.done
rename did. This is why I commented that some more thinking is likely
needed about how to handle seeing those only-makes-sense-in-recovery
options when not being started for recovery/standby; it's not obvious
that any approach will make everyone happy.

If you want to do something special yourself to clean that up, there's
already recovery_end_command available for that. Let's say you wanted
to force the old name and did "include_if_exists conf.d/recovery.conf",
to trick it even if the patrolling for the name idea goes in. Now you
could do:

recovery_end_command = 'rm -f /tmp/pgsql.trigger.5432 && mv
conf.d/recovery.conf conf.d/recovery.done'

Like some people are used to and might still prefer for some reason.
There'd be time left over to head out to the lawn and yell at the kids
there. Actually, this might be the right approach for tools that are
trying to change as little as possible but add quick 9.2 compatibility.

I think there's enough pluggable bits in every direction here that
people can assemble the setup they'd like out of the available parts,

Maybe these slightly different semantics between archive recovery and
standby mode are exactly why they should be kicked off by differently
named files?

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us