On Sun, Jul 26, 2015 at 07:35:57PM -0400, Jan Wieck wrote:
> On 07/25/2015 10:51 AM, Steve Singer wrote:
> >On Fri, 24 Jul 2015, David Fetter wrote:
> >
> >>Folks,
> >>
> >>While in the best of all possible worlds, we'd have planned out a
> >>replication strategy before we get tables whose initial sync via
> >>"SUBSCRIBE SET" will never finish, we aren't always given that much
> >>ability to plan that soon.
> >>
> >>CLONE is great when you want to light an Nth node for N > 2, but
> >>that's just adjusting an extant cluster, not creating one in the first
> >>place.
> >>
> >>What stands between the state of the slony code and being able to
> >>clone an origin node?
> >
> >My guess is that the hardest part of teaching slony how to do this would be
> >to figure out how to get the proper values in sl_setsync such that it knows
> >where to start replication from when it starts up as a subscriber.
> 
> Correct.
> 
> The latest version of Slony uses that approach. The subscription process
> does store an sl_setsync entry according to the snapshot of copy_set with an
> empty action list.
> 
> If there was a switch to pg_dump to somewhere save the txid_snapshot that it
> dumped, that would be a good starting point to artificially create the first
> replica.

As on 9.5, pg_dump has a --snapshot option, which could use the output
of some other snapshot-capturing process.  Would that serve?

> That said, pg_dump isn't that much faster than Slony's copy_set() so
> we'd need to find a way to reconstruct an sl_setsync entry from
> something like a binary base backup. That is not trivial.

Reconstruct it, or just get a copy of it in a known state?

Cheers,
David.
-- 
David Fetter <david at fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate