Jan Wieck wrote:
> On 8/18/2006 4:59 PM, Niels Breet wrote:
>> On Fri, August 18, 2006 18:44, Christopher Browne wrote:
>>> This just popped up on IRC; it looks worth discussion...
>>>
>>>
>>> (09:04:50) *X-Fade:* Hmm I found my problem I think..
>>> (09:04:52) *X-Fade:* ERROR: Slony-I: logTrigger() called in non-client
>>> session (09:05:47) *X-Fade:* Making a trigger on a subscribed table
>>> that
>>> inserts in a table that get replicated from that node doesn't work?
>>>
>>> (09:30:06) *X-Fade:* Hmm this commit is the reason why it doesn't work:
>>> http://gborg.postgresql.org/pipermail/slony1-commit/2005-April/000528.html
>>>
>>>  (09:30:46) *X-Fade:* But I guess there was never thought about the
>>> case
>>> that a replicated table triggers a insert into another replicated
>>> table..
>>> (10:03:28) *X-Fade:* Hmm yeah, commenting the elog out fixes my
>>> problem..
>>>
>>>
>>> ===================================================================
>>> RCS file:
>>> /usr/local/cvsroot/slony1/slony1-engine/src/backend/slony1_funcs.c,v
>>> retrieving revision 1.17.2.5 retrieving revision 1.17.2.6 diff
>>> -Lsrc/backend/slony1_funcs.c -Lsrc/backend/slony1_funcs.c -u -w
>>> -r1.17.2.5 -r1.17.2.6
>>> --- src/backend/slony1_funcs.c
>>> +++ src/backend/slony1_funcs.c
>>> @@ -430,9 +430,8 @@
>>> case SLON_ROLE_NORMAL:    /* Normal, that's good */ break;
>>>
>>> -        case SLON_ROLE_SLON:    /* Replication session, nothing to
>>> do here */
>>> -            SPI_finish();
>>> -            return PointerGetDatum(NULL);
>>> +        case default:    /* non-client session ??? */
>>> +            elog(ERROR, "Slony-I: logTrigger() called in non-client
>>> session");
>>> }
>>>
>>>
>>>
>>> -------------------
>>>
>>>
>>> Apparently X-Fade had a trigger on a subscriber that triggered updates
>>> to a table replicated in another set (I'm speculating here...)
>>
>> yep, that is what happened.
>>
>> Node is subscriber for table A and has an ON INSERT trigger that inserts
>> in another table B. That node is origin for table B, so it has a
>> logtrigger. The logtrigger on B checks if the trigger is fired in a
>> client
>> session or by slon and gives the error.
>>
>>> Is there a reason why this shouldn't be permitted to work?
>> I hope not :)
>
> Thinking about it, the entire check is there from a time that assumed
> the log trigger would actually be defined on a subscriber. It is not.
> Instead there is the deny update trigger in place. So removing the
> entire check would eventually be the right course of action?
>
Sounds good to me; I'm sure others would like that course :-)