On Sat, Aug 20, 2016 at 01:43:42PM +0900, Michael Paquier wrote:
> On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <bruce@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 <bruce@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 +