On 07/27/2015 07:49 PM, Steve Singer wrote:
> Or am I still missing something?

No, I missed the part that the transactions still in progress at the 
next SYNC after backup start will be handled by precisely that.

So the logic then is to take the last master-SYNC found on the restored 
slave, increase maxxid in it to the highest txid found in sl_log_*, 
remove all txids found in sl_log_* from the xip vector and use that as 
sl_setsync. Add a sl_confirm entry for that master-SYNC reflecting that 
the slave is caught up to/beyond that point and that the next SYNC to 
process is the one following the backup start.

There is only one detail left then. While we are doing all that we need 
the postmaster for the restored slave up and running. But we need to 
make sure that the slon of the master (or any node for that matter) does 
not connect to the slave and get confused by seeing the wrong data. That 
may be accomplished by changing the local node ID last so that every 
slon would throw an error because they are connecting to the wrong node.


Jan

-- 
Jan Wieck
Senior Software Engineer
http://slony.info