Josh Berkus <j...@agliodbs.com> writes: > As I said elsewhere, I think that a modified version of Simon's proposal > gets us all what we want except code cleanliness. I'd like to hear from > Tom on that issue.
Well, code complexity is hard to gauge without coding a draft implementation, but I think this largely fails on UI complexity. It's still paying too high a price for backwards compatibility IMO. The more I read about this, the more doubtful I am that unifying PITR recovery with standby mode is a good idea from the UI perspective. They may share a lot of common infrastructure but they need to be triggered in fundamentally different ways. In particular, one of the reasons that recovery.conf/.done was set up the way that it was was to have a simple way of letting the system get out of PITR mode; without that, a crash during PITR recovery is going to lead to restarting from the PITR start point (because when we restart, we find configuration settings telling us to do that). We could possibly move the necessary state into pg_control, but keeping it as a GUC is going to be a mess. On the whole I still think a trigger file is a sane design for that. It may make sense to move the configuration data somewhere else, but we really need to be able to tell the difference between "starting PITR", "continuing PITR after a mid-recovery crash", and "finished PITR, up and running normally". A GUC is not a good way to do that. The angst around this issue seems to me to largely stem from trying to use a configuration setup designed for one-shot PITR scenarios for hot standby scenarios, which are really pretty different. We have to divorce those two cases before we're going to have something that's sane and usable ... and AFAICS that means giving up backwards compatibility to some degree. We got this wrong in 9.0, which everyone understood at the time was an unpolished prototype implementation of replication. I don't think it's sensible to now move the goalposts and decree that we've got to be fully backward compatible with our first-cut mistakes. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers