On 10/6/2004 12:33 AM, Brad Hilton wrote:
> On Oct 5, 2004, at 6:27 PM, Jan Wieck wrote:
> 
>> On 10/5/2004 4:55 PM, Brad Hilton wrote:
>>
>>> Jan Wieck wrote:
>>>> In that debug session, could you please do:
>>>>     frame 2
>>>>     print *type_cache
>>> (gdb) print *type_cache
>>> $1 = {type_id = 137443440, typlen = 0, typbyval = 0 '\0', typalign = 
>>> 0 '\0',
>>>    btree_opc = 0, hash_opc = 131072, eq_opr = 1254030516, lt_opr = 
>>> 1257342180,
>>>    gt_opr = 138395880, cmp_proc = 0, eq_opr_finfo = {fn_addr = 0x195,
>>>      fn_oid = 3221211424, fn_nargs = 4, fn_strict = 0 '\0', fn_retset 
>>> = 0 '\0',
>>>      fn_extra = 0x0, fn_mcxt = 0x4, fn_expr = 0x806f0e4}, 
>>> cmp_proc_finfo = {
>>>      fn_addr = 0xe61d17b4, fn_oid = 0, fn_nargs = 14416, fn_strict = 
>>> 49 '1',
>>>      fn_retset = 8 '\b', fn_extra = 0x11, fn_mcxt = 0xbfffc918,
>>>      fn_expr = 0x81e6645}}
>>>> Another question is "what got dropped to cause this"? I can only 
>>>> assume that some some data type definition changes or column type 
>>>> changes have been invoked in this. But this is pure guessing.
>>> That would surprise me.  I am not knowingly changing any column types 
>>> or data types, and this crash happens every time I initialize the 
>>> slony triggers.  I should also mention that I'm using tsearch2, but 
>>> the module seems pretty harmless.  It just adds a few new data types 
>>> and functions.
>>
>> Well, looking at the tsearch2 module shows a couple of "complex" data 
>> types, which of course don't have equal operator functions ... so this 
>> is a smoking gun to me. What type in pg_type has oid 137443440?
> 
> Hmm, there is no pg_type row with an oid of 137443440.  Perhaps it was 
> a type related to slony?  Of course I've installed the slony schema by 
> now (to avoid the core dumps...), so I can't be certain.  Would it help 
> if I got another backtrace and verified the pg_type oid that is 
> referenced in type_cache before uninstalling the nodes?
> 
> -Brad

I was able to reproduce a similar core by using a simple user defined 
data type that has no comparision operators at all - just input and 
output functions and nothing else. Slony does not have such data type. 
The xxid type coming with it is a full blown type that even comes with 
an opclass for indexing. But tsearch2 has a few of those critters. Could 
it be that after uninstalling Slony, you also uninstalled and eventually 
reinstalled tsearch2 in that database?

However, this is a serious bug since user defined types without any 
operators are of course legal in Postgres and have to be supported by 
Slony. I am working on a fix for it.


Jan

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