On Sat, Sep 24, 2011 at 6:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> ... The time to replace it is now and I >> welcome that day and have already agreed to it. > > Okay, so you do agree that eventually we want to be rid of > recovery.conf? I think everyone else agrees on that. But if we are > going to remove recovery.conf eventually, what is the benefit of > postponing doing so?
I am happy that we don't recommend the use of recovery.conf in the future, and that the handling of the contents of recovery.conf should be identical to the handling of postgresql.conf. The latter point has always been the plan from day one. (I should not have used "it" in my sentence, since doing so always leads to confusion) My joyous rush into agreeing to removal has since been replaced with the cold reality that we must support backwards compatibility. Emphasise "must". >> The semantics are clear: recovery.conf is read first, then >> postgresql.conf. It's easy to implement (1 line of code) and easy to >> understand. > > It's not clear to me why the override order should be that way; I'd have > expected the other way myself. So this isn't as open-and-shut as you > think. I agree with you that recovery.conf as an override makes more sense, though am happy with either way. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers