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