On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > I note also that replication slots aren't backed up by pg_dump; I see > analogy here and think that at least some parts of logical replication will > be similar and not require DDL at all, just as slots do not.
I agree with that. Of course, it's *impossible* to usefully back up a slot because the key ingredient in a slot is the LSN after which WAL should be preserved - and it's meaningless to preserve that across a dump and restore cycle. But, for example, replication set definitions can be preserved across a dump and restore and I am quite sure users will find it very unfortunate if they aren't.
There should be some way of dumping and restoring these sorts of structures,
and if I were thinking of the name of a tool to dump them, it seems to me
that pg_dump is a pretty good name for it... (Look for slonikconfdump.sh
for the latest iteration of the Slony variation, if interested...)
I have implemented "slony_dump" a couple of times; if that had become a
built-in, I sure hope a pg_dump flag could have been the thing to request
such.
The same seems likely true of FDW configuration; it sure would be nice to
be able to dump that in a consistent, reusable way. Again, nice to have
that be an extension of pg_dump.
Replication configuration should be able to be dumped out in a form that can be readily loaded somewhere else. It might not be something to have pg_dump do by default, but it should sure be somewhere; if it isn't, then
that's a reasonably serious shortcoming. Slony didn't have such until
2009; a serious implementation of Logical Replication shouldn't wait
that long.
If what gets spit out is a series of
select replicate_these_relations('['public']');
requests, well, I can actually live with that.
In the long run, it's preferable to have
ALTER SCHEMA PUBLIC ENABLE REPLICATION;
but if the desired syntax isn't clear, at the start, we can surely live with
having functions, initially, as long as:
a) We know that's not intended as being the ultimate solution;
b) There's *some* sort of upgrade path that is helpful to indicate the
syntax that falls out;
c) There's tooling to dump out cluster information, whatever the syntax
form.
I'm getting quoted on being OK with not having syntax, initially...
I'm still fine with that, but take the above caveats to see my intent.
--
When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"