Message-Id: <199511210706.XAA19178@gaia.CS.Berkeley.EDU>
From: aoki@CS.Berkeley.EDU (Paul M. Aoki)
To: Robert Patrick <Robert_Patrick@methi.ndim.edrc.cmu.edu>
Cc: postgres-arch@postgres.Berkeley.EDU
Subject: Re: Postgres 4.2 question 
Reply-To: aoki@CS.Berkeley.EDU (Paul M. Aoki)
In-reply-to: Your message of Tue, 21 Nov 1995 01:45:27 -0500 
	     <199511210645.WAA15240@nobozo.CS.Berkeley.EDU> 
Date: Mon, 20 Nov 95 23:06:22 -0800
Sender: aoki@postgres.Berkeley.EDU

Robert Patrick <Robert_Patrick@methi.ndim.edrc.cmu.edu> writes:
> 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:

i don't know what the problem with inversion large objects is.  jolly
said i had injected some problem into pg95 -- i didn't know pg4.2 had
a problem with them as well.  (aside from the fact that writing into
existing inversion files screws things up in really weird ways.)

i don't think the problem is so much the pg_proc entry, which should
in this case be innocuous.  other people have seen that thing with the
hash functions getting bogus values; at one point, i dove into the
hash code (in mariposa) to make it pass regression -- it's so fucked
up in pg4.2 that it's unusable.  i think jolly put some of my fixes
into pg95, but i don't remember.  anyway, there are many, many
problems in the pg4.2 code -- start with the fact that bucket splits
and overflows send you into code paths that call routines with
incorrect arguments, completely wrong logic, etc.  the locking logic
looks fairly random -- i just turned off the page locking and used
table locking.  vacuum can't vacuum pg4.2 hash indices because the
person who wrote them forgot to implement backward traversal, so if
you delete an index tuple the vacuum index scan gets lost.  (i noticed
later that vacuuming of hash indices was commented out of the pg4.2
regression test..)
--
  Paul M. Aoki          |  University of California at Berkeley
  aoki@CS.Berkeley.EDU  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776