Dave Price wrote: > Hi, > > I am trying to get slony to replicate a single table from an existing > database. > > My initial test is using a backup of that table in a separate database > (different servers actually) > > I am able to run the pgbench example okay. > > When I use my own data, the master will start up fine, but the > subscriber node always says: > > > [EMAIL PROTECTED]:~/proj/slony]$ ./start_cdr_slave.sh > 2006-11-29 14:35:02 MST CONFIG main: slon version 1.1.5 starting up > 2006-11-29 14:35:02 MST CONFIG main: local node id = 1 > 2006-11-29 14:35:02 MST CONFIG main: launching sched_start_mainloop > 2006-11-29 14:35:02 MST CONFIG main: loading current cluster configuration > 2006-11-29 14:35:02 MST CONFIG storeSet: set_id=1 set_origin=1 > set_comment='test cdr table' > 2006-11-29 14:35:02 MST CONFIG main: configuration complete - starting threads > 2006-11-29 14:35:02 MST DEBUG1 localListenThread: thread starts > 2006-11-29 14:35:02 MST FATAL localListenThread: "select > "_cdr01".cleanupNodelock(); insert into "_cdr01".sl_nodelock values ( > 1, 0, "pg_catalog".pg_backend_pid()); " - ERROR: duplicate key > violates unique constraint "sl_nodelock-pkey" > 2006-11-29 14:35:02 MST DEBUG1 slon: shutdown requested > [EMAIL PROTECTED]:~/proj/slony]$ > > > I found some notes about the duplicate key error, but they talk about > a 2nd slon process, which I am sure is not running. > > 1> What causes this when I create the the master and slave db's from scratch? > > 2> Is there a way to fix it in place - without dropping the replca and > starting all over? > > Thanks for any help!! > > There may not be a slon process running, although I suggest you check again, just in case; I've been certain of such things myself, and found myself wrong :-(.
The alternative thing is that perhaps there is still a database connection open on the PG backend. We have periodically had this problem when running Slony-I across a WAN, where some component (firewall / Cisco router / IPSec tunnel appliance) got deranged, which caused the connection to get broken. Unfortunately, it is possible for that breaking of the connection to happen in such a way that while the slon figures out that it needs to create a new connection, the PG backend is unaware that there's no "other side" for it to talk to. As far as the backend is concerned, there's still an incoming connection, albeit one that's pretty silent. There's some TCP/IP default that will make this timeout after ~2hrs (I don't offhand know where that is configured; presumably somewhere in your OS'es kernel config). You can search for such connections using pg_stat_activity; you may just need to kill off a backend process (which "trumps" that 2hr timeout) to fix things... _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
