| 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: | Whole Thread | Raw Message | 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 |