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
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 |