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?


Jan

> 
> 
> - Niels
> 
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


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