Darren Reed <darrenr+postgres@fastmail.net> writes:
> Tom Lane wrote:
>> I'm curious though exactly where the failure is, because there's not
>> much in RelationCacheInitializePhase2 that looks like it could crash,
> #0 0x08298378 in RelationCacheInitializePhase2 () at relcache.c:2394
> 2394 LOAD_CRIT_INDEX(AttributeRelidNumIndexId);
> (gdb) where
> #0 0x08298378 in RelationCacheInitializePhase2 () at relcache.c:2394
> #1 0x082ac19c in InitPostgres (dbname=0x83ba450 "postgres",
> username=0x83c1428 "postgres") at postinit.c:459
Hmph. AFAICS the only possible way it could dump core right there is
if RelationBuildDesc returned NULL or a bogus pointer. And
RelationBuildDesc does have a NULL return defined: if it couldn't find
a pg_class row for the relation. (So we probably ought to add an
explicit error test to LOAD_CRIT_INDEX --- surprising it hasn't been
seen before.) Anyway it seems that the problem is you are missing
the pg_class row for pg_attribute_relid_attnum_index. And possibly
other stuff too; this crash is mighty early in initialization and
only a couple of core tables have been touched yet. What I fear
is that one or more whole pages of pg_class have been lost --- either
zeroed out or corrupted in a way that heapscan doesn't notice. You
might be able to learn something from pg_filedump if you're interested
in pursuing this for forensic purposes, but I'm afraid the odds of
getting anything back from this database are mighty low.
regards, tom lane