Re: [GENERAL] question about replication slots

[Andreas Kretschmer]

Michael Paquier  wrote:

> On Sat, Dec 5, 2015 at 2:35 AM, Andreas Kretschmer
>  wrote:
> > imagine a streaming replication using physical replication slots. And 
> > sometime a
> > fail over. All okay. I take a basebackup and rebuild the old master as 
> > slave.
> >
> > Is there a risk that the new slave contains active replication slots but no
> > listener on it?
> 
> Yes. This would retain WAL on the standby indefinitely if you are not careful.
> 
> > What have i to consider?
> 
> You had better remove the contents of pg_replslot/ in the backup
> taken. Even if you include them, there are high chances that those
> will be useless at the end.
> 
> So, quoting the docs
> (http://www.postgresql.org/docs/devel/static/continuous-archiving.html):

Thx for the answer!


Andreas
-- 
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.  (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.  N 51.05082°, E 13.56889°


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] question about replication slots

[Michael Paquier]

On Sat, Dec 5, 2015 at 2:35 AM, Andreas Kretschmer
 wrote:
> imagine a streaming replication using physical replication slots. And 
> sometime a
> fail over. All okay. I take a basebackup and rebuild the old master as slave.
>
> Is there a risk that the new slave contains active replication slots but no
> listener on it?

Yes. This would retain WAL on the standby indefinitely if you are not careful.

> What have i to consider?

You had better remove the contents of pg_replslot/ in the backup
taken. Even if you include them, there are high chances that those
will be useless at the end.

So, quoting the docs
(http://www.postgresql.org/docs/devel/static/continuous-archiving.html):
It is often a good idea to also omit from the backup dump the files
within the cluster's 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.
-- 
Michael


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] question about replication slots

[Andreas Kretschmer]

Hi @ll,

imagine a streaming replication using physical replication slots. And sometime a
fail over. All okay. I take a basebackup and rebuild the old master as slave.

Is there a risk that the new slave contains active replication slots but no
listener on it? What have i to consider?

Thx.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general