I think this is a valuable effort, but I wonder how we are going to arrive at a consensus. I don't see any committer supporting these changes. Clearly, there are some advantages to having recovery parameters be GUCs, but the proposed changes also come with some disadvantages, and the tradeoffs aren't so clear.
For example, putting recovery target parameters into postgresql.conf might not make sense to some people. Once you have reached the recovery end point, the information is obsolete. Keeping it set could be considered confusing. Moreover, when I'm actually doing point-in-time-recovery attempts, I don't think I want to be messing with my pristine postgresql.conf file. Having those settings separate isn't a bad idea in that case. Some people might like the recovery.done file as a historical record. Having standby.enabled just be deleted would destroy that information once recovery has ended. In the past, when some people have complained that recovery.conf cannot be moved to a configuration directory, I (and others?) have argued that recovery.conf is really more of a command script file than a configuration file (that was before replication was commonplace). The premise of this patch is that some options really are more configuration than command most of the time, but that doesn't mean the old view was invalid. The current system makes it easy to share postgresql.conf between primary and standby and just maintain the information related to the standby locally in recovery.conf. pg_basebackup -R makes that even easier. It's still possible to do this in the new system, but it's decidedly more work. These are all "soft" reasons, but they add up. The wins on the other hand are obscure: You can now use SHOW to inspect recovery settings. You can design your own configuration file include structures to set them. These are not bad, but is that all? I note that all the new settings are PGC_POSTMASTER, so you can't set them on the fly. Changing primary_conninfo without a restart would be a big win, for example. Is that planned? It might be acceptable to break all the old workflows if the new system was obviously great, but it's not. It's still confusing as heck. For example, we would have a file "standby.enabled" and a setting "standby_mode", which would mean totally different things. I think there is also some conceptual overlap between standby_mode and recovery_target_action (standby_mode is really something like recovery_target_action = keep_going). I also find the various uses of "trigger file" or "to trigger" confusing. The old trigger file to trigger promotion makes sense. But calling "standby.enabled" a trigger file as well confuses two entirely different concepts. I have previously argued for a different approach: Ready recovery.conf as a configuration file after postgresql.conf, but keep it as a file to start recovery. That doesn't break any old workflows, it gets you all the advantages of having recovery parameters in the GUC system, and it keeps all the options open for improving things further in the future. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
