Re: postgres 8.2.6 core dump when initialising.

From: Darren Reed <darrenr+postgres(at)fastmail(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: postgres 8.2.6 core dump when initialising.
Date: 2008-04-14 14:04:09
Message-ID: 48036459.7040503@fastmail.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Tom Lane wrote:
> Darren Reed <darrenr+postgres(at)fastmail(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2008-04-14 14:32:42 Re: postgres 8.2.6 core dump when initialising.
Previous Message Tom Lane 2008-04-14 13:32:28 Re: postgres 8.2.6 core dump when initialising.