On Tuesday November 9 2004 5:58, cbbrowne at ca.afilias.info wrote:
> > On Monday November 8 2004 8:59, Jan Wieck wrote:
> >> On 11/8/2004 9:58 PM, Ed L. wrote:
> >> > I just had a 1.0.5 initial "copy set" fail after 2 hours of data
> >> > copying. This was not slony's fault; the slon process got clobbered.
> >> > Unfortunately, it rolled back all 2 hours of progress.  I don't have
> >> > a patch to offer for this, but it would be nice to be able to commit
> >> > partially thru the copy set and pick up where it left off ...
> >>
> >> Right, it would be nice. But I failed to figure out how to do this
> >> without relying on the masters MVCC features while at the same time
> >> ensuring that restarting against a possibly all the time heavily
> >> updated master would still lead to a consistent initial copy. I don't
> >> expect a patch ... I would settle for an idea.
> >
> > I wonder if you could somehow take note of a progress checkpoint after
> > some
> > amount of time on the nearest "truncateTable(...); copy table" boundary
> > after the amount of time elapses?  Maybe sl_table.tab_initialized =
> > false until each table is committed on the slave, then
> > sl_table.tab_initialized
> >
> > := 'true'?  Then, if lights go out, you pick up with slave listing of
> >
> > tables where sl_table.tab_initialized = false before moving on to
> > events. Not sure that qualifies as a usable idea.
>
> Alas, no...  The problem is in determining which table updates since the
> COPY SET started need to be applied to the subscriber.
>
> If everything is done as one transaction, the answer is simple:  All of
> it.
>
> Elsewhere lies madness, or at least something similar to madness.

I see the madness, no way to bookmark progress on the master without getting 
way into MVCC.  Not a big deal.  If it hurts to clobber a slon after 2 
hours of copying, a good workaround exists:  don't do that!  It is the same 
story for clobbering a dump or load from dump.

Ed