On 28 March 2013 08:31, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 27.03.2013 23:36, Simon Riggs wrote:
>>
>> Why do you think recovery_config_directory are different to
>> config_file with respect to pg_basebackup?
>
>
> pg_basebackup doesn't try to *write* anything to config_file. It does write
> to $PGDATA/recovery.conf, with the expectation that it takes effect when you
> start the server.
>
> When you take a backup, I think it's quite reasonable that if you have set
> config_file to a different location, that's not backed up. Same with
> recovery.conf. But when pg_basebackup *creates* recovery.conf, it's at least
> surprising if it doesn't take effect.
No, it *would* take effect. The parameter is set in a config file that
is not part of the backup, so if you start the server from the backup
then it doesn't know that the recovery_config_directory had been set
and so it would read the recovery.conf written by pg_basebackup. If
you backup the parameter files as well, then it would fail, but that
is easily handled by saying the recovery.conf can exist either in
datadir or recovery_config_directory. I don't see that as a major
problem, or change. But for other reasons, I have revoked the patch.
You have highlighted that pg_basebackup does *not* take a fully
working backup in all cases, especially the -R case where it is
clearly broken. It is that pre-existing issue that leads to your
complaint, not the patch itself.
Please admit that by adding a line to the docs to explain the
non-working case of -R.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
