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/