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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
