On 28.03.2013 14:45, Simon Riggs wrote:
On 28 March 2013 11:36, Robert Haas<robertmh...@gmail.com>  wrote:
On Thu, Mar 28, 2013 at 6:23 AM, Simon Riggs<si...@2ndquadrant.com>  wrote:
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.

Are you saying pg_basebackup doesn't back up postgresql.conf?  I thought it did.

postgresql.conf will be backed up if it is present in the data
directory. If it is not present, it is not backed up.

Right.

Therefore anybody using pg_basebackup and the config_file parameter
does *not* have an executable backup when used with the -R option, as
Heikki was suggesting was a requirement for this patch.

That's not related to the -R option, the situation with config_file is the same with or without it. But yes, if you use config_file option to point outside the data directory, the config file won't be backed up. That feels intuitive to me, I wouldn't expect it to be. Same with include or include_dir directives in the config file, as well as hba_file and ident_file - I wouldn't expect any of the files that those point to to be included in the backup.

The filesystem-level backup procedure documented in the user manual, not using pg_basebackup, behaves the same.

pg_basebackup's behaviour with respect to .conf files is undocumented
so its a "feature" that it skips .conf files in the config_file case.

Ok. It's always beem self-evident to me, but I agree it should be documented. How about the attached?

- Heikki
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index e444b1c..987802a 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -920,7 +920,10 @@ SELECT pg_stop_backup();
     If you are using tablespaces that do not reside underneath this directory,
     be careful to include them as well (and be sure that your backup dump
     archives symbolic links as links, otherwise the restore will corrupt
-    your tablespaces).
+    your tablespaces). If you have relocated any configuration files
+    outside the database cluster directory (see
+    <xref linkend="config-includes"> and
+    <xref linkend="runtime-config-file-locations">), include them as well.
    </para>
 
    <para>
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index 9fe440a..bdf74a0 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -512,7 +512,11 @@ PostgreSQL documentation
    The backup will include all files in the data directory and tablespaces,
    including the configuration files and any additional files placed in the
    directory by third parties. Only regular files and directories are allowed
-   in the data directory, no symbolic links or special device files.
+   in the data directory, no symbolic links or special device files. If you
+   have relocated any configuration files outside the data directory (see
+   <xref linkend="config-includes"> and
+   <xref linkend="runtime-config-file-locations">), they will not be included
+   in the backup.
   </para>
 
   <para>
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to