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
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. |