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:

Reply via email to