| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Replication identifiers, take 4 |
| Date: | 2015-04-29 02:00:13 |
| Message-ID: | 55403B2D.8040401@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/24/15 4:29 PM, Andres Freund wrote:
>> Shouldn't this be backed up by pg_dump(all?)?
>
> Given it deals with LSNs and is, quite fundamentally due to concurrency, non transactional, I doubt it's worth it. The other side's slots also aren't going to be backed up as pg dump obviously can't know about then. So the represented data won't make much sense.
I agree it might not be the best match. But we should consider that we
used to say, a backup by pg_dumpall plus configuration files is a
complete backup. Now we have replication slots and possibly replication
identifiers and maybe similar features in the future that are not
covered by this backup method.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-04-29 03:48:20 | Re: shared_libperl, shared_libpython |
| Previous Message | Dave Jones | 2015-04-29 01:46:43 | Re: Temporal extensions |