Message-ID: <48036459.7040503@fastmail.net>
Date: Mon, 14 Apr 2008 07:04:09 -0700
From: Darren Reed <darrenr+postgres@fastmail.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-admin@postgresql.org
Subject: Re: postgres 8.2.6 core dump when initialising.
References: <4802F108.2090709@fastmail.net> <1071.1208179948@sss.pgh.pa.us>
In-Reply-To: <1071.1208179948@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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