Re: replication slots replicated to standbys? - Mailing list pgsql-hackers

<p dir="ltr"><p dir="ltr">On 21 Aug 2016 12:36 AM, "Bruce Momjian" <<a
href="mailto:bruce@momjian.us">bruce@momjian.us</a>>wrote:<br /> ><br /> > On Sat, Aug 20, 2016 at 01:43:42PM
+0900,Michael Paquier wrote:<br /> > > On Sat, Aug 20, 2016 at 1:39 PM, Bruce Momjian <<a
href="mailto:bruce@momjian.us">bruce@momjian.us</a>>wrote:<br /> > > > Someone reported that a replication
slotthat existed at the time a base<br /> > > > backup was done on the master was copied to the standby. 
Becausethey<br /> > > > didn't realize it, their WAL was not being recycled on the standby.<br /> > >
><br/> > > > Is that possible?  Is it a known behavior?  I don't see it documented.<br /> > ><br />
>> >From backup.sgml:<br /> > >    <para><br /> > >     It is often a good idea to also omit
fromthe backup the files<br /> > >     within the cluster's <filename>pg_replslot/</> directory, so
that<br/> > >     replication slots that exist on the master do not become part of the<br /> > >   
 backup. Otherwise, the subsequent use of the backup to create a standby<br /> > >     may result in indefinite
retentionof WAL files on the standby, and<br /> > >     possibly bloat on the master if hot standby feedback is
enabled,because<br /> > >     the clients that are using those replication slots will still be connecting<br />
>>     to and updating the slots on the master, not the standby.  Even if the<br /> > >     backup is only
intendedfor use in creating a new master, copying the<br /> > >     replication slots isn't expected to be
particularlyuseful, since the<br /> > >     contents of those slots will likely be badly out of date by the
time<br/> > >     the new master comes on line.<br /> > >    </para><br /> > ><br /> > >
Noteas well that pg_basebackup omits its content and creates an empty<br /> > > directory.<br /> ><br /> >
Seemslike another good idea to use pg_basebackup rather than manually<br /> > doing base backups;  Magnus has been
sayingthis for a while.<p dir="ltr">The main time that's an issue is when you're rsync'ing to save bandwidth, using CoW
volumesnapshots, etc. pg_basebackup becomes totally impractical on big systems.<p dir="ltr">> I supposed there is no
waywe could remove this error-prone behavior<br /> > because replication slots must survive server restarts.  Is
thereno way<br /> > to know if we are starting a standby from a fresh base backup vs.<br /> > restarting a
standby? In that case we could clear the replication<br /> > slots.  Are there any other error-prone things copied
fromthe master?<p dir="ltr">We could remove slots when we enter archive recovery. But I've recently implememted support
forlogical decoding from standbys, which needs slots. Physical slot use on standby is also handy. We cannot tell
whethera slot was created on the replica or created on the master and copied in the base backup and don't want to drop
slotscreated on the replica.<p dir="ltr">I also have use cases for slots being retained in restore from snapshot, for
re-integratingrestored nodes into an MM mesh.<p dir="ltr">I think a recovery.conf option to remove all slots during
archiverecovery could be handy. But mostly it comes down to tools not copying them.