Thu Oct 18 02:42:40 PDT 2007
- Previous message: [Slony1-general] Re-enabling replication for dropped table.
- Next message: [Slony1-general] Re-enabling replication for dropped table.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thanks for the prompt response, Dave. On Thu, October 18, 2007 11:06 am, David Rees wrote: > The easiest solution will be to drop replication from those nodes and > restart from scratch. If you can afford the time to do this, that > should work. ja, I though of that - just such a mission for a single table though. I'm loath to take that horrible Microsoft approach. > Otherwise, someone with more internal Slony knowledge will have to > chime in on what tables will have to be mucked with before adding the > table to a new set and merging the sets together. Muck is the right word. Slony's (seems) great, but crikey, what a complicated system. Then again, maybe it just seems that way because it's so bloody complicated to work with. I think slony needs *another* layer on top of slonik - so much of it is hit and miss. How about this: how does slony determine the last argument for the _db_cluster.logtrigger() trigger? _db_cluster.logtrigger('_db_cluster', '2', 'vvk'): :: '_db_cluster' is obvious - that's the DB name. :: '2' is the tab_id (from schema.sl_table) :: what is that ever-growing series of 'v's in 'vvk'? If I can determine what to stick in there, then I can try recreating that trigger manually and see what happens. Regards Henry -- Zen Search SA http://zen.co.za/
- Previous message: [Slony1-general] Re-enabling replication for dropped table.
- Next message: [Slony1-general] Re-enabling replication for dropped table.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list