On 27 March 2013 14:20, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > On 27.03.2013 15:09, Simon Riggs wrote: >> >> On 27 March 2013 12:12, Heikki Linnakangas<hlinnakan...@vmware.com> >> wrote: >>> >>> On 27.03.2013 13:47, Simon Riggs wrote: >>>> >>>> >>>> Allow external recovery_config_directory >>>> If required, recovery.conf can now be located outside of the data >>>> directory. >>>> Server needs read/write permissions on this directory. >>> >>> >>> This was a surprising commit. Does this get us any closer to merging >>> postgresql.conf and recovery.conf? >> >> >> Why so? I made a clear proposal on how to proceed and this was the >> first part of it. > > > You didn't answer the question. Does this get us any closer to merging > postgresql.conf and recovery.conf? Why is this bundled in with that?
Why do you think these points are bundled? It clearly isn't and I've not claimed it gets us any closer to that goal. But it is the first part of two agreed changes. And I am now working on the second, which is the recovery.conf GUCs. > ISTM the quickest way forward is to revert this, and proceed with the rest > of the plan: get Michael/Fujii's patch into shape, and commit it. If we > still think this additional GUC is a good idea after that, we can add it > afterwards just as well. My review of that patch is on file and my rejection of it clear for all to see. I have proposed a way forwards, which achieved agreement then and I have made it clear all the way that I would work on that, and am now doing so. None of that is a surprise. And Fujii will receive credit for his contribution, which is the bit where we make recovery parms into GUCs. The quickest way forward is to proceed with The Plan as agreed on Dec 24 - Jan 9. Restarting a discussion and formulating an alternative plan is just deliberate interference with no justification, especially not when we pretend that the later plan somehow supercedes the earlier agreed one, and certainly not just because a few months went by in between. In summary, we have clear agreement that a file needs to trigger recovery. We have no reason to believe that renaming the trigger file to something else is a good thing, hence recovery.conf should remain and its contents be treated as GUCs. And recovery.conf now has the option of living in a different directory, which needs to be writable. So we have the new features desired, plus backwards compatibility. And off I go to code now. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
