Fiel Cabral wrote:

>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.
>  
>
You understand, I trust, that restoring old configuration in this manner 
means that you have to treat the subscribers as having been destroyed.

>>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.
>  
>

It seems as though your application treats the database as a "document" 
that you expect to save and reload at will.

That doesn't fit with Slony-I's intent:

"Slony-I is a system intended for data centers and backup sites, where 
the normal mode of operation is that all nodes are available all the 
time, and where all nodes can be secured. If you have nodes that are 
likely to regularly drop onto and off of the network, or have nodes that 
cannot be kept secure, Slony-I is probably not the ideal replication 
solution for you."

I am increasingly getting the impression that Slony-I may not be quite 
be ideal for you.

>>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 do you mean by "get this to work" aside from "it didn't emit error 
messages, so maybe something is happening?"

>>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.
>  
>
Based on your elaboration, I'm not sure what you are trying to 
accomplish by adding Slony-I to your application.

If you're willing to let users reinitialize the application at will by 
giving them a GUI widget to reload the DBMS from scratch, I don't see 
what advantage would be expected from getting Slony-I involved in the 
process, and I foresee some disadvantages.

You may be able to get something about this configuration to appear to 
"function;" whether it is doing you much good is another matter.

Slony-I _isn't_ the answer to all problems...