On Oct 15, 2013, at 7:49 PM, Greg Sabino Mullane <[email protected]> wrote:

> On Tue, Oct 15, 2013 at 10:02:43AM -0700, David E. Wheeler wrote:
> ...
>> It will also need to deactivate any other kids associated with the tables 
>> to be copied, and then re-activate them when it’s done.
> 
> Yes, I've gone back and forth on this. First, it should only do so when 
> its copies of tables and dbgroups matches a sync exactly.

Which would be the case for the case where you ask it to `clone sync=foobar`.

> Second, I'm not sure there is a need to - the delta syncs should be very 
> short, and I think MVCC will take care of everything.

Well, they may not be that short. What if I have tables with 1m rows I want to 
clone? Will take a while.

> The truncates may cause issue though. I'll think about this some more.

I think it would need some testing to see what happens in various situations. 
Like when someone does an insert while the truncate and copy is running.

> We would need a smooth way to handle the kids too - it may be enough to 
> simply kill the kid, let clone slip in, and then the CTL resurrects the kid 
> who gets in line behind the clone process?

That sounds like it might work.

>> Does onetimecopy even work in the 5.0 branch?
> 
> No.

Well in that case, I’ve reassigned this issue to you. :-)

 https://github.com/bucardo/bucardo/issues/37

> I should be more clear - the above scenario only happens when people 
> explicitly request it. In which case, caveat emptor. A use case for 
> that is a swap sync with alternating sequences that needs to be brought 
> online.
> 
> I have in mind that the CLI will complain if you try to clone a 
> multi-source sync, and demand you pick a "winner" or give it the 
> go ahead and do the above.
> 
> I'm also envisioning a pretty print out and final confirmation before 
> all clone events, as it is a pretty major dropped row "are you sure?" 
> moment.

Ah, okay, that makes much more sense.

Thanks!

David


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Bucardo-general mailing list
[email protected]
https://mail.endcrypt.com/mailman/listinfo/bucardo-general

Reply via email to