Robert, > In most cases we either break backwards compatibility or require some > type of switch to turn on backwards compatibility for those who want > it. While the above plan tries to do one better, it leaves me feeling > that the thing I don't like about this is that it sounds like you are > forcing backwards compatibility on people who would much rather just > do things the new way. Given that, I foresee a whole new generation > of > confused users who end up setting their configs one way only to have > someone else set the same config in the other file, or some tool dump > out some config file, overriding what was really intended. This will > also make things *harder* for those tool providers you are trying to > help, as they will be forced to support the behavior *both ways*. I'd > much rather see some type of switch which turns on the old behavior > for those who really want it, because while you can teach the new > behavior, if you can't prevent the old behavior, you're creating > operational headaches for yourself.
This is a good point. There's also the second drawback, which is complexity of code, which I believe that Tom Lane has brought up before; having two separate-but-equal paths for configuration is liable to lead to a lot of bugs. So, we have four potential paths regarding recovery.conf: 1) Break backwards compatibility entirely, and stop supporting recovery.conf as a trigger file at all. 2) Offer backwards compatibility only if "recovery_conf='filename'" is set in postgresql.conf, then behave like Simon's compromise. 3) Simon's compromise. 4) Don't ever change how recovery.conf works. The only two of the above I see as being real options are (1) and (2). (3) would, as Robert points out, cause DBAs to have unpleasant surprises when some third-party tool creates a recovery.conf they weren't expecting. So: (1) pros: * new, clean API * makes everyone update their tools * no confusion on "how to do failover" * code simplicity cons: * breaks a bunch of 3rd-party tools * or forces them to maintain separate 9.1 and 9.2 branches (2) pros: * allows people to use only new API if they want * allows gradual update of tools * can also lump in relocatable recovery.conf as feature cons: * puts off the day when vendors pay attention to the new API (and even more kicking & screaming when that day comes) * confusion about "how to do failover" * code complexity -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers