On 28 March 2013 08:31, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers