In response to "Diego Algorta Casamayou" <diego.algorta at gmail.com>:

> On Jan 22, 2008 11:16 AM, Raymond O'Donnell <rod at iol.ie> wrote:
> > On 22/01/2008 13:11, Diego Algorta Casamayou wrote:
> >
> > > What usage could I give to this restored database? May I use it as a
> > > master in case the master died? In that case I think a failover to the
> > > running slave would be faster.
> >
> > Well, it's a backup - no more and no less. The whole point of Slony (or
> > any replication system) is that you have a nearly-up-to-date copy of
> > your database to which you can failover if the master goes belly-up. A
> > backup is always going to be less current than a well-running Slony slave.
> 
> I know, I know. But for example, I currently have full backups made
> from my master node. And restoring that backup to use it as an
> independent database doesn't really work because it still has slony
> all over the place. Running UNINSTALL NODE on it doesn't work either.
> 
> >
> > > What should I do to use it in a non-replicated environment? A staging
> > > environment, for example for testing purposes where I need
> > > production-like data.
> >
> > That's what I do; as well as keeping a copy as a backup, of course. :-)
> 
> OK. But what do you do to get rid of slony on that restored database?

DROP SCHEMA _[clustername] CASCADE;
... always works for me.

> This should be a common issue, but I can't find a clear note on it on
> the documentation.

Don't know why that's not documented.  Anyone?

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran at collaborativefusion.com
Phone: 412-422-3463x4023