On Mon, 24 Jan 2005 15:57:25 -0500, Christopher Browne
<cbbrowne at ca.afilias.info> wrote:
> Fiel Cabral <e4696wyoa63emq6w3250kiw60i45e1 at gmail.com> writes:
> > Thanks for the tip Vivek but I have a lot of primary key columns
> > that were generated by Slony.
> 
> "Best practices" involve putting primary keys on yourself, as various
> grief is possible if you leave some other system responsible for
> primary keys.
> 
> If you can avoid having Slony-I do that, it would be a good thing.
> 
Ok I'll follow the best practices, thanks. I'll heed the warnings.

> 
> The notices are not a problem.  What I would be concerned about is the
> handling of OIDs; the table IDs will change when you recover the
> database, and Slony-I _does_ care about that.
> 
> Could you elaborate on what you are doing when you restore the
> database?
> 
I have a GUI application wherein the user can select "Restore
Configuration" from the menu. The configuration is stored in my server
app in a custom format backup file generated by pg_dump. I just want
to allow the user to restore old configurations if they want to revert
to older settings.

> I find it pretty surprising that you are using pg_restore and
> expecting to use the resultant database for replication straight away.
> 

I hoped to do that but I was mistaken.


> In fact, it seems curious that you would need to do so; are you
> running into such severe failures in your environment that it makes
> sense to routinely recover nodes in this manner?
> 

No. My server application used to not have replication and it was able
to use pg_dump to make backups and restore from those backups using
pg_restore. I was trying to see if I can still get this to work even
if replication is in play.

> What I would have expected you to do is to indicate that the node had
> failed, perhaps doing a FAILOVER to let another node take over, and
> then reinitialize the failed node.  That's the usual "use" for
> Slony-I...

I'll take a look at this. Thank you.