On Tue, Apr 8, 2014 at 3:08 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, Apr 8, 2014 at 1:18 AM, Robert Haas <robertmh...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
