Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us