agora inbox for postgres@postgres.berkeley.edu
help / color / mirror / Atom feedFrom: Paul M. Aoki <aoki@CS.Berkeley.EDU>
To: postgres-arch@postgres.Berkeley.EDU
Subject: [Robert_Patrick@methi.ndim.edrc.cmu.edu: Postgres 4.2 question]
Date: Mon, 20 Nov 95 23:07:44 -0800
Message-ID: <199511210707.XAA19646@gaia.CS.Berkeley.EDU> (raw)
------- Forwarded Message
From: Robert Patrick <Robert_Patrick@methi.ndim.edrc.cmu.edu>
To: aoki@postgres.Berkeley.EDU
Subject: Postgres 4.2 question
Date: Tue, 21 Nov 1995 01:45:27 -0500
Hi Paul,
You'll never believe what I'm doing... Hell, I swore I'd never look at this
code again but we're trying to get ready for a beta release (and they wouldn't
let me port to Postgres95 before the release...). Basically, I'm trying to
track down what is causing Postgres 4.2 to dump core when running vacuum.
I have already added a hack to prevent it from trying to vacuum inversion
large objects (or their indices). It appears that the problem it's having now
is in vacuuming an index on one of our tables. After spending several hours
poking around in gdb, the only thing I have found is that the function manager
is calling the hashtext function with two arguments (pg_proc.pronargs = "2"),
even though the function is defined like this:
uint32
hashtext(key)
struct varlena *key;
This is causing the keylen in hashtext to start at 1075574716 which *must* be
garbage...
How can this possibly work? Better yet, why is the pg_proc table (apperently)
out of synch with the database? I just need a sanity check...
Thanks a lot,
Robert
Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x120048578 in hashtext (key=0x1400aec40)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hashfunc.c:254
(gdb) where
#0 0x120048578 in hashtext (key=0x1400aec40)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hashfunc.c:254
#1 0x12017dc0c in fmgr_c (user_fn=0x120048510 <hashtext>, func_id=456,
n_arguments=2, values=0x11fffcfd0, isNull=0x11fffcfc0 "")
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/utils/f
mgr/fmgr.c:56
#2 0x12017e118 in fmgr (va_alist=456)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/utils/f
mgr/fmgr.c:197
#3 0x12004e898 in _hash_call (rel=0x1401c58a0, metad=0x1400df380,
key=5369424960)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hashutil.c:111
#4 0x12004d3c8 in _hash_search (rel=0x1401c58a0, keysz=1,
scankey=0x1401bef78, bufP=0x11fffd228, metap=0x1400df380)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hashsearch.c:55
#5 0x12004d8ec in _hash_first (scan=0x1401bef40)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hashsearch.c:177
#6 0x12004729c in hashgettuple (scan=0x1401bef40, dir=1 '\001')
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
hash/hash.c:296
#7 0x12017dc0c in fmgr_c (user_fn=0x120047210 <hashgettuple>, func_id=440,
n_arguments=2, values=0x11fffd350, isNull=0x11fffd340 "")
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/utils/f
mgr/fmgr.c:56
#8 0x12017e118 in fmgr (va_alist=440)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/utils/f
mgr/fmgr.c:197
#9 0x120058d80 in index_getnext (scan=0x1401bef40, direction=1 '\001')
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/access/
index/indexam.c:366
#10 0x12008342c in _vc_vaconeind (curvrl=0x14018fc60, indrel=0x1401c58a0)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/command
s/vacuum.c:579
#11 0x1200831e4 in _vc_vacindices (curvrl=0x14018fc60, onerel=0x1401c3e20)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/command
s/vacuum.c:526
#12 0x120082980 in _vc_vacone (p=0x1401b1920, curvrl=0x14018fc60)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/command
s/vacuum.c:303
#13 0x120082484 in _vc_vacuum ()
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/command
s/vacuum.c:146
#14 0x120082248 in vacuum ()
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/command
s/vacuum.c:43
#15 0x120155df0 in ProcessUtility (command=370, args=0x0,
commandString=0x11fffd978 "vacuum", dest=Debug)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/tcop/ut
ility.c:648
#16 0x12014f918 in pg_eval_dest (query_string=0x11fffd978 "vacuum", argv=0x0,
typev=0x0, nargs=0, dest=Debug)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/tcop/po
stgres.c:601
#17 0x12014f7e4 in pg_eval (query_string=0x11fffd978 "vacuum", argv=0x0,
typev=0x0, nargs=0)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/tcop/po
stgres.c:562
#18 0x120150e04 in PostgresMain (argc=4, argv=0x11ffffa48)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/tcop/po
stgres.c:1239
#19 0x12009b7ec in main (argc=4, argv=0x11ffffa48)
at /afs/cs.cmu.edu/project/edrc-ndim7/postgres-kerberos/src/backend/main/ma
in.c:48
------- End of Forwarded Message
--
Paul M. Aoki | University of California at Berkeley
aoki@CS.Berkeley.EDU | Dept. of EECS, Computer Science Division (#1776)
| Berkeley, CA 94720-1776
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: postgres@postgres.berkeley.edu
Cc: aoki@CS.Berkeley.EDU, postgres-arch@postgres.Berkeley.EDU
Subject: Re: [Robert_Patrick@methi.ndim.edrc.cmu.edu: Postgres 4.2 question]
In-Reply-To: <199511210707.XAA19646@gaia.CS.Berkeley.EDU>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox