Re: replication slots replicated to standbys?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replication slots replicated to standbys?
Date: 2016-08-20 04:43:42
Message-ID: CAB7nPqQw_HbkLnt__OGXP2nu=G_8=H=myA3Y5NpV5B5qtnGY7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <bruce(at)momjian(dot)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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-08-20 04:50:28 Re: CLUSTER, reform_and_rewrite_tuple(), and parallelism
Previous Message Bruce Momjian 2016-08-20 04:39:39 replication slots replicated to standbys?