Re: Request for vote to move forward with recovery.conf overhaul
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2013-03-13T11:50:54Z
Lists: pgsql-hackers
Attachments
- 20130313_recovery_guc.patch (application/octet-stream) patch
Hi all,
Please find attached an updated patch doing what is written below.
On Mon, Mar 4, 2013 at 11:25 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> Robert wrote a good summary:
> 1. Get rid of recovery.conf - error out if it is seen
> 2. For each parameter that was previously a recovery.conf parameter, make
> it a GUC
> 3. For the parameter that was "does recovery.conf exist?", replace it with
> "does standby.enabled exist?".
>
There are still a couple of things missing:
- pg_basebackup supports an option --write-recovery-conf, I haven't
modified anything yet, but I think that we should replace that by an option
that write standby.enabled in base backup and adds the relevant parameters
in postgresql.conf. Any input on that is welcome.
- no migration guide is written yet. Where to write it? I think I will need
some help here...
- The current error message if recovery.conf is found in data folder is
that:
+ if (AllocateFile(RECOVERY_COMMAND_FILE, "r") != NULL)
+ ereport(FATAL,
+ (errmsg("\"%s\" is not supported anymore as
a recovery method",
+ RECOVERY_COMMAND_FILE),
+ errdetail("Refer to appropriate
documentation about migration methods")));
Any better ideas?
I found some inconsistent behavior when a slave had no standby.enabled
files and recovery settings: the slave with "hot_standby = on" tried to
recover WAL files from archives instead of failing with errors of the type
"could not locate required checkpoint record" and then stop. This is fixed.
Regards,
--
Michael