agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

From: Paul M. Aoki <aoki@CS.Berkeley.EDU>
To: Robert Patrick <Robert_Patrick@methi.ndim.edrc.cmu.edu>
Cc: postgres-arch@postgres.Berkeley.EDU
Subject: Re: Postgres 4.2 question
Date: Mon, 20 Nov 95 23:06:22 -0800
Message-ID: <199511210706.XAA19178@gaia.CS.Berkeley.EDU> (raw)
In-Reply-To: <199511210645.WAA15240@nobozo.CS.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

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, Robert_Patrick@methi.ndim.edrc.cmu.edu, postgres-arch@postgres.Berkeley.EDU
  Subject: Re: Postgres 4.2 question
  In-Reply-To: <199511210706.XAA19178@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