From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joshua Berkus <josh(at)agliodbs(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-09-25 20:17:30 |
Message-ID: | 5585.1316981850@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joshua Berkus <josh(at)agliodbs(dot)com> writes:
> include_if_exists certainly solves the recovery.conf/recovery.done problem. We can even phase it out, like this:
> 9.2: include_if_exists = 'recovery.conf' in the default postgresql.conf file.
> 9.3: include_if_exists = 'recovery.conf' commented out by default
> 9.4: renaming recovery.conf to recovery.done by core PG code removed.
> This gives users/vendors 3 years to update their scripts to remove dependence on recovery.conf. I'm afraid that I agree with Simon that there's already a whole buncha 3rd-party code out there to support the current system.
If there is indeed code out there that depends on the current system,
why do you think that waiting several releases to change it will make
things better? I think it's more likely that we'd just have *more* code
that needs to be changed, and no reduction in the pain level when the
transition does finally happen.
In any case, I thought we'd agreed that the use of that file as a flag
should go away now, so I quite fail to understand your comment about 9.4.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-09-25 21:12:34 | Re: fix for pg_upgrade |
Previous Message | Joshua Berkus | 2011-09-25 20:13:20 | Re: unite recovery.conf and postgresql.conf |