On 11/29/2005 5:46 PM, Sven Willenberger wrote:

> 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

And I thought we had made it clear in the documentation that Slony-I is 
putting the system catalog of a subscriber into a corrupted state that 
makes DDL statements like that playing Russian Roulette *sigh*.

The correct solution to this is EXECUTE SCRIPT (EXECUTE ONLY ON=...) 
together with STORE TRIGGER.


Jan

PS: corrupted <> messed up. Slony knows very well what it did and how to 
fix those corruptions in order to execute DDL scripts, for failover and 
uninstall.

> 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


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #