Re: catalog corruption bug

On Sat, 7 Jan 2006, Tom Lane wrote:

> Fascinating --- that's not anywhere near where I thought your problem
> was.  Which cache is this tuple in?  (Print *ct->my_cache)

$2 = { id = 3, cc_next = 0x2aaaaaac1048, cc_relname = 0x2aaaaab19df8 "pg_amop", cc_reloid = 2602, cc_indexoid = 2654,
cc_relisshared= 0 '\0', cc_tupdesc = 0x2aaaaab199e0, cc_reloidattr = 0, cc_ntup = 3, cc_nbuckets = 256, cc_nkeys = 2,
cc_key= {5, 1, 0, 0}, cc_hashfunc = {0x44e1a0 <hashoid>, 0x44e1a0 <hashoid>, 0, 0}, cc_skey = {{     sk_flags = 0,
sk_attno= 5,     sk_strategy = 3,     sk_subtype = 0,     sk_func = {       fn_addr = 0x5bb8c0 <oideq>,       fn_oid =
184,      fn_nargs = 2,       fn_strict = 1 '\001',       fn_retset = 0 '\0',       fn_extra = 0x0,       fn_mcxt =
0x914998,      fn_expr = 0x0     },     sk_argument = 0   }, {     sk_flags = 0,     sk_attno = 1,     sk_strategy = 3,
   sk_subtype = 0,     sk_func = {       fn_addr = 0x5bb8c0 <oideq>,       fn_oid = 184,       fn_nargs = 2,
fn_strict= 1 '\001',       fn_retset = 0 '\0',       fn_extra = 0x0,       fn_mcxt = 0x914998,       fn_expr = 0x0
},    sk_argument = 0   }, {     sk_flags = 0,     sk_attno = 0,     sk_strategy = 0,     sk_subtype = 0,     sk_func =
{      fn_addr = 0,       fn_oid = 0,       fn_nargs = 0,       fn_strict = 0 '\0',       fn_retset = 0 '\0',
fn_extra= 0x0,       fn_mcxt = 0x0,       fn_expr = 0x0     },     sk_argument = 0   }, {     sk_flags = 0,
sk_attno= 0,     sk_strategy = 0,     sk_subtype = 0,     sk_func = {       fn_addr = 0,       fn_oid = 0,
fn_nargs= 0,       fn_strict = 0 '\0',       fn_retset = 0 '\0',       fn_extra = 0x0,       fn_mcxt = 0x0,
fn_expr= 0x0     },     sk_argument = 0   }}, cc_isname = "\000\000\000", cc_lists = {   dll_head = 0x935018,
dll_tail= 0x934c50 }, cc_bucket = {{     dll_head = 0x0,     dll_tail = 0x0   }}
 
}

Am I correct in interpreting this as the hash opclass for Oid?  That's
really bizarre.  Definately didn't change that.

> The tableOid implies it's one of the caches on pg_amop, which makes
> the whole thing stranger yet.  pg_amop doesn't change during normal
> operation so there's no reason for one of its tuples to become dead.
> You aren't creating/deleting operator classes in this database are
> you?

Nope.  As a matter of fact, I never created any custom operator classes in
this database.

>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

-- 
Given my druthers, I'd druther not.