On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote: > On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <br...@momjian.us> wrote: > > Someone reported that a replication slot that existed at the time a base > > backup was done on the master was copied to the standby. Because they > > didn't realize it, their WAL was not being recycled on the standby. > > > > Is that possible? Is it a known behavior? I don't see it documented. > > >From backup.sgml: > <para> > It is often a good idea to also omit from the backup the files > within the cluster's <filename>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. > </para> > > Note as well that pg_basebackup omits its content and creates an empty > directory.
Seems like another good idea to use pg_basebackup rather than manually doing base backups; Magnus has been saying this for a while. I supposed there is no way we could remove this error-prone behavior because replication slots must survive server restarts. Is there no way to know if we are starting a standby from a fresh base backup vs. restarting a standby? In that case we could clear the replication slots. Are there any other error-prone things copied from the master? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
