Re: postgres 8.2.6 core dump when initialising.

Tom Lane wrote:
> Darren Reed <darrenr+postgres@fastmail.net> writes:
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x0829845c in RelationCacheInitializePhase2 () at relcache.c:2400
> > 2400                    LOAD_CRIT_INDEX(TriggerRelidNameIndexId);
> > (gdb) where
> > #0  0x0829845c in RelationCacheInitializePhase2 () at relcache.c:2400
>
> This appears to be the exact same problem you reported back in February:
> http://archives.postgresql.org/pgsql-admin/2008-02/msg00370.php
>
> I'm thinking there must be something about what you are doing that
> is triggering this issue.  Care to give us a full data dump on your
> maintenance habits?

So, from time to time I run an online pg_dump of all the tables as a backup
but not often enough (of course.)

Some time ago I saw this message:
ERROR:  index "pg_depend_reference_index" contains unexpected zero page
at block 23
HINT:  Please REINDEX it.
ERROR:  index "table_p_hash_idx" contains unexpected zero page at block 7
HINT:  Please REINDEX it.

...and the end result was that I needed to take the database
down into single user mode and reindex it.  I read up on it
and it appears that this problem occurs with specific work
load types - whatever that is, I appear to fit.
Not a big problem.

More recently, I've seen postgres get "stuck" doing an insert
and spin doing nothing.  I tried to grab a core with gcore but
it didn't cooperate.  The evidence for that was the usual "INSERT"
next to the postgres process.  This wasn't fun to deal with,
kill -INT had no affect, kill -TERM had no effect and this I was
left with kill -QUIT.  The database has always started up cleanly
after this, so I didn't think too much of it (should have done
another dump....sigh...)  After the last instance of this problem,
I ran an online REINDEX over all of the tables hoping that this
might solve the problem but not long after, I hit the OID problem.


> It might be useful if we could look at a pg_filedump dump of your
> pg_class table, too.

How do I know which one is pg_class?

I can tell which ones hold the data ;)

Darren