Re: Including replication slot data in base backups

On Thu, Apr 10, 2014 at 12:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 8, 2014 at 3:08 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Tue, Apr 8, 2014 at 1:18 AM, Robert Haas <robertmhaas@gmail.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.

This makes me think that it's safer to just remove replication slot files
at the beginning of the recovery when both backup_label and recovery.conf
exist.

Regards,

-- 
Fujii Masao