On 4/5/2006 7:15 PM, Gavin Hamill wrote: > Oh dear - why is nothing ever easy? :( > > I've just tried to gracefully swap master/slave roles with little success...
Briefly stopping and forcibly disconnecting all clients (pgpool is very handy for that) from both, the old and the new origin, usually makes switchover a lot smoother and faster. Since obviously the MOVE SET happened on node 1 but wasn't able to complete on node 2, you must have had some backend on node 2 that kept a lock on one of the replicated tables, preventing the event to replicate. Slon needs to put back all the user constraints, remove the deny_access trigger and put the log trigger into place on the new origin, so it needs an access_exclusive table lock on the entire set. What you've done at this point, while slon on node 2 was waiting to get those locks, is to destroy that event in the UNINSTALL NODE panic move (and I assume you also stopped or restarted slon on node 2) before it did replicate. With that event info gone, node 2 is still a perfectly valid subscriber of a non-existent node. Restarting the postmaster of node 2 or any client application accessing node 2 should have been enough. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
