On 5/3/2005 9:32 AM, Hannu Krosing wrote:
> On T, 2005-05-03 at 15:05 +0300, Hannu Krosing wrote:
>> This started happening a few weeks ago (at least I noticed it then) on a
>> quite busy database. happens from once every 2-3 days to  once or twice
>> a day.
>> 
>> Is it a known problem ?

No, not known yet

>> 
>> (gdb) bt
>> #0 0x4028158f in strlen () from /lib/libc.so.6
>> #1 0x520f6a47 in slon_quote_literal (str=0x0) at slony1_funcs.c:1073
>> #2 0x520f5dcd in _Slony_I_logTrigger (fcinfo=0xbfffde60) at
>> slony1_funcs.c:762
>> #3 0x082445b7 in fmgr_internal_function ()
>> #4 0x08111f9d in FreeTriggerDesc ()
>> #5 0x08113316 in ExecARUpdateTriggers ()
>> 
>> It happens for normal insert/update query (in a pl/pgsql function), and
>> does not happen when I run that function again.
> 
> some more infobits:
> 
> the trigger is defined as :
> 
> _balance_cluster.logtrigger('_balance_cluster', '1052', 'vvvvvvkv')
> 
> and some of the columns preceeding the 'k' can be NULL.

I presume this is 1.0.5 ... unless the log trigger lost count of the 
attribute number due to dropped columns somehow (and there is code to 
cope with that), it must be exactly the 'k' column.

There is unfortunately no check that guards against that, so if by any 
chance the other trigger (which are BEFORE triggers?) manage to put a 
NULL value into it, that would certainly explain things.

> 
> I don't see any reason for the key itself to be NULL, except that there
> are 2 more triggers  (in pl/pgsql) running on the same relation which
> may have some way to corrupt something in the cache or TriggerData or
> tupdesc.
> 


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