Return-Path: owner-postman
Received: from gaia.CS.Berkeley.EDU (gaia.CS.Berkeley.EDU [128.32.37.31]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with ESMTP id XAA13024 for <postgres-arch>; Mon, 20 Nov 1995 23:07:44 -0800
Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by gaia.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id XAA19646 for postgres-arch; Mon, 20 Nov 1995 23:07:44 -0800
Message-Id: <199511210707.XAA19646@gaia.CS.Berkeley.EDU>
X-Authentication-Warning: gaia.CS.Berkeley.EDU: Host localhost.Berkeley.EDU didn't use HELO protocol
From: aoki@CS.Berkeley.EDU (Paul M. Aoki)
To: postgres-arch@postgres.Berkeley.EDU
Reply-To: aoki@CS.Berkeley.EDU (Paul M. Aoki)
Subject: [Robert_Patrick@methi.ndim.edrc.cmu.edu: Postgres 4.2 question]
Date: Mon, 20 Nov 95 23:07:44 -0800
Sender: aoki@postgres.Berkeley.EDU
X-Mts: smtp

------- 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
