Re: Including replication slot data in base backups

On Tue, Apr 8, 2014 at 3:08 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Apr 8, 2014 at 1:18 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Not sure if this is exactly the right way to do it, but I agree that
>> something along those lines is a good idea. I also think, maybe even
>> importantly, that we should probably document that people using
>> file-copy based hot backups should strongly consider removing the
>> replication slots by hand before using the backup.
> Good point. Something here would be adapted in this case:
> http://www.postgresql.org/docs/devel/static/backup-file.html
> I am attaching an updated patch as well.

What you've got here doesn't look like the right section to update -
the section you've updated is on taking a cold backup. The section I
think you want to update is "Making a Base Backup Using the Low Level
API", and specifically this part:

You can, however, omit from the backup dump the files within the
cluster's pg_xlog/ subdirectory. This slight adjustment is worthwhile
because it reduces the risk of mistakes when restoring. This is easy
to arrange if pg_xlog/ is a symbolic link pointing to someplace
outside the cluster directory, which is a common setup anyway for
performance reasons. You might also want to exclude postmaster.pid and
postmaster.opts, which record information about the running
postmaster, not about the postmaster which will eventually use this
backup. (These files can confuse pg_ctl.)

What I'd propose is adding a second paragraph like this:

It is often a good idea to also omit from the backup dump the files
within the cluster's pg_replslot/ directory, so that replication slots
that exist on the master do not become part of the backup. Otherwise,
the subsequent use of the backup to create a standby may result in
indefinite retention of WAL files on the standby, and possibly bloat
on the master if hot standby feedback is enabled, because the clients
that are using those replication slots will still be connecting to and
updating the slots on the master, not the standby. Even if the backup
is only intended for use in creating a new master, copying the
replication slots isn't expected to be particularly useful, since the
contents of those slots will likely be badly out of date by the time
the new master comes on line.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company