On 4/22/2005 2:08 PM, Tom Lane wrote:

> Sven Willenberger <sven@dmv.com> writes:
>> We have a replication set up between 2 servers using Slony; both are
>> runnind PostgreSQL 8.0.1. The issue is that when updates/inserts are
>> made to a replicated table, the replication does not occur; apparently
>> this is due to spi_exec somehow not allowing/causing the slony trigger
>> function to fire.
>
> Yuck :-(. The only idea that comes to mind is that 8.0 changed the
> timing of trigger firing --- the triggers are probably firing while your
> function still has control, whereas in earlier releases they'd only fire
> after it returns. Could this be breaking some assumption Slony makes
> about the order of operations?
>
> regards, tom lane

Slony triggers are AFTER ROW triggers. All they do is one SPI_execp() to
insert the log row. The only way that could possibly be suppressed is by
bypassing the executor and doing direct heap_ access.

So how does plperl manage that?


Jan

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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match