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