Re: pg_autovacuum w/ dbt2 - Mailing list pgsql-hackers

Mark Wong <markw@osdl.org> writes:
> Ok, well I got a core dump with 8.0rc4, but I'm not sure if it's
> exactly the same problem.  I have the postgres binary and the core
> here:
>     http://developer.osdl.org/markw/pgsql/core/2files.tar.bz2
> But it's for ia64, if you got one.

Poking around with gdb, it seems that the scankey structure being used
by SearchCatCache got clobbered; which is a bit surprising because
that's just a local variable in that function, and hence isn't really
very exposed.  The contents of cache->cc_skey are okay, but cur_skey[0]
and cur_skey[1] don't match, which implies the clobber happened
somewhere between lines 1110 and 1217 of catcache.c.

(gdb) f 8
#8  0x400000000039c970 in SearchCatCache (cache=0x200000001f1e0140, v1=0,   v2=6917529027641871376, v3=4294966252,
v4=6917546619827097184)  at catcache.c:1217
 
1217    in catcache.c
(gdb) p cache->cc_skey
$7 = {{sk_flags = 0, sk_attno = -2, sk_strategy = 3, sk_subtype = 0,   sk_func = {fn_addr = 0x200000000003a9c8, fn_oid
=184, fn_nargs = 2,     fn_strict = 1 '\001', fn_retset = 0 '\0', fn_extra = 0x0,     fn_mcxt = 0x600000000009e550,
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}, {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}}
 
(gdb) p cur_skey
$8 = {{sk_flags = 0, sk_attno = 1, sk_strategy = 24932, sk_subtype = 24948,   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 =
1043},{sk_flags = 0, sk_attno = 1043, sk_strategy = 0,   sk_subtype = 4294967295, 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}, {
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}}
 

The core dump happens because we eventually try to jump through the
zeroed-out fn_addr function pointer.

Not sure what to make of this.  That's extremely heavily used,
well-debugged code; it's hard to believe that there are any intermittent
bugs in it.

I notice that the backend seems to have been using some nonstandard C
code:

Error while reading shared library symbols:
/home/markw/dbt2/storedproc/pgsql/c/../../../storedproc/pgsql/c/funcs.so: No such file or directory.

What is that, and how much confidence have you got in it?
        regards, tom lane