On Thu, Apr 10, 2014 at 12:36 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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. Yes, that's far better than what I sent. Thanks! -- Michael
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
