Re: unite recovery.conf and postgresql.conf

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

In response to

Browse pgsql-hackers by date

  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