Thanks all for your help! :-)

I ended up dropping the replication and manually recuperate. I was surprised 
by a few discrepancies between the two databases (triggers in the master 
that were not replicated) and a few problems with meta data that were not in 
the replication set anyway. Plus, pressure to restore...

I took the easy way out and did it manually because I knew what to do.

On the other hand, there were hard lessons learned. First, if I'm going to 
replicate I will now replicate everything. Things change; even those things 
that aren't supposed to. Second, there is absolutely no excuse for not 
simulating problems and be prepared. I should have been prepared for 
something like that, but four years without a glitch dulls the senses. :-)

Thanks again!

-- 

Philippe

------
The trouble with common sense is that it is so uncommon.
<Anonymous>

On Monday 22 March 2010 04:37:18 Stéphane A. Schildknecht wrote:
> Le 21/03/2010 15:37, Philippe Clérié a écrit :
> > I am trying to recover from a catastrophe and I am about to do
> > something new and I need some reassurance that it's the correct
> > procedure.
> >
> > I have a Slony replication set with two nodes in a master/slave
> > configuration, Postgresql 8.1, Slony 1.2.1 on Debian Etch. Node1
> > (master) was taken out of commission (think a rm -rf * type error).
> > I've recovered from a previous backup that's about 3 weeks out of date,
> > but Node2 is up to date. I want Node2 to update Node1 and then I want
> > to go back to normal.
> 
> (...)
> 
> As you only have two nodes, I think you'd better drop the replication
>  from the 2 nodes and recreate it from scratch, having node2 as provider.
> 
> Once Node1 is synced with node2, you could do a move set.
> 
> Best regards,
>