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. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
