Re: unite recovery.conf and postgresql.conf

Josh Berkus <josh(at)agliodbs(dot)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