On Tue, 2005-11-29 at 17:20 -0500, Jan Wieck wrote:
> On 11/29/2005 3:28 PM, Sven Willenberger wrote:
> 
> > On Tue, 2005-11-29 at 15:09 -0500, Sven Willenberger wrote:
> >> Slony 1.1.2, FreeBSD 6.0, Postgresql 8.0.4
> >> 
> >> I currently have a table that I am replicating to a subscriber node
> >> containing customer information. I have added a trigger to the
> >> subscriber version of this table to fire after insert that should create
> >> a new table using information from the newly inserted record; this
> >> trigger does not seem to fire.
> >> 
> >> Does Slony bypass user triggers on the subscriber node's tables? If so,
> >> is there any way to bypass this behavior? If not, any ideas why this
> >> trigger may not be firing?
> >> 
> >> Sven
> >> 
> >> _______________________________________________
> > 
> > Please disregard; there were apparently a batch of records that were
> > being updated rather than inserted (that had already existed prior to
> > the replication scheme being enabled); further testing with adding new
> > records reveals that the after update triggers on subscriber nodes in
> > fact do work.
> > 
> > I apologize for the noise.
> 
> I hope that you did not create the trigger in the subscriber database 
> via direct DDL after Slony-I was installed. On a Slony-I node all DDL 
> must be run via the slonik command EXECUTE SCRIPT.

My set up is as follows:

Origin: 
CustomerTable

Subscriber:
CustomerTable
After Insert on CustomerTable execute trigger -> this trigger creates a
new table which does not exist on origin.

So yes, I did create the trigger on the replicated CustomerTable after
it had been created and replication started. But as a) this is an after
insert trigger that does not affect the table at all and b) the
resulting table that the trigger creates is not needed on the origin
node I did not think this would hurt anything.

If I use Execute script, would this not create the same trigger on the
origin and subscriber nodes? As I am running a partial replication
scheme where origin and subscriber actually maintain on a small subset
of common tables, this would work with my plan.

The issue I would see here is if the trigger would fail for some reason
then the SYNC would fail. However, even in this case, would not fixing
the cause of the failure (on the subscriber node) allow for the SYNC to
complete?

Sven