Skip site navigation (1) Skip section navigation (2)

Re: pg_autovacuum w/ dbt2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Wong <markw(at)osdl(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org
Subject: Re: pg_autovacuum w/ dbt2
Date: 2005-01-13 02:17:33
Message-ID: 4201.1105582653@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-www
Mark Wong <markw(at)osdl(dot)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

In response to

Responses

pgsql-www by date

Next:From: Marc G. FournierDate: 2005-01-13 03:25:52
Subject: Re: [Gforge-admins] Moving the server?
Previous:From: Greg Sabino MullaneDate: 2005-01-13 01:53:51
Subject: Re: Documentation in new design unreadable

pgsql-hackers by date

Next:From: Jeff DavisDate: 2005-01-13 02:45:09
Subject: Re: Much Ado About COUNT(*)
Previous:From: Mark WongDate: 2005-01-12 23:44:29
Subject: Re: pg_autovacuum w/ dbt2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group