Re: [HACKERS] Index corruption

Tom Lane wrote:

> pg_proc_prosrc_index is the problem, eh?  I'll bet a nickel that you're
> seeing still another manifestation of btree's problems with oversized
> index entries.  (See recent thread 'Error "vacuum pg_proc"'.)
>
> [...]
>
> 7.0 should fix this problem, but it's a real hazard in 6.5.

    I  already  posted  a patch that removes pg_proc_prosrc_index
    from 6.5.2.  This one is definitely not fixable  by  anything
    else (except changing all functions to <2700).

    Anyway,  I still think that a new implementation of reindexdb
    would be good. Some of the system indices can cause big,  big
    trouble,  if  they  get corrupted. If you would ever be faced
    with a corrupted pg_class_... index, you  won't  be  able  to
    dump  any  more,  because the backend will fail to startup at
    all.

    I analyzed the problem of recreating system  catalog  indices
    some weeks ago, and ISTM that during bootstrap operation, ALL
    tuples are visible.

    I hacked in a "drop index" for the bootstrap parser, and on a
    freshly  created  DB some hand-made BKI script ran smooth and
    recreated  all  the  indices  well.  But  it  failed  on  the
    regression  DB,  bacause it bombed out with duplicate errors.
    First I was a little puzzled  about  it,  because  I  allways
    thought  that  only  vacuum removes index tuples. So it could
    only be the main tuples visibility  that  prevents  from  dup
    errors between vacuum times.

    Thus,  IMHO  there  should  be  another  command added to the
    bootstrap parser.  This would recreate ALL  existing  indices
    (system  and user ones), but tell the visibility code somehow
    to ignore deleted tuples. I don't have the time to do it now,
    so at least I'd like to have a TODO item for it.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #