On 11/9/2004 12:43 AM, Ed L. wrote:

> On Monday November 8 2004 10:37, Ed L. 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.
> 
> Duh.  Now I see your point about changing master.   Hmm.

Exactly! You not only need to get the initial data, you also need to get 
all (and only those) changes that happened to that data after the point 
at which you logically copied it, with respect to MVCC visibility of 
your COPY transaction.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #