Re: Including replication slot data in base backups

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Including replication slot data in base backups
Date: 2014-04-02 09:46:23
Message-ID: D2F8C9799F9B34D41E3E5D62@apophis.credativ.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--On 1. April 2014 11:26:08 -0400 Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

>
> As a general comment, I think that replication slots, while a great
> feature, have more than the usual potential for self-inflicted injury.
> A replication slot prevents the global xmin from advancing (so your
> tables will bloat) and WAL from being removed (so your pg_xlog
> directory will fill up and take down the server). The very last thing
> you want to do is to keep around a replication slot that should have
> been dropped, and I suspect a decent number of users are going to make
> that mistake, just as they do with prepared transactions and backends
> left idle in transaction.

Oh yes, i saw this happening uncountless times now by customers when
restoring a basebackup with in-progress prepared xacts (and was indeed
fooled myself a few times, too). I always was under the impression that
there should be a big big warning at least in the logs to hint the user to
check any remaining prepared xacts...

--
Thanks

Bernd

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-02 09:58:10 Re: Including replication slot data in base backups
Previous Message Michael Meskes 2014-04-02 09:40:05 Re: using arrays within structure in ECPG