On Wed, 08 Apr 2009 10:59:54 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Ivan Sergio Borgonovo <mail@webthatworks.it> writes:
> > 2009-04-08 16:36:53 CEST LOG: startup process (PID 3176) was
> > terminated by signal 11: Segmentation fault 2009-04-08 16:36:53
> > CEST LOG: aborting startup due to startup process failure
>
> Hmm, what Postgres version is this? Can you get a stack trace from
> the startup process crash?
How on Debian?
Debian does all it's automagic stuff in init. I never learned how to
start pg manually.
> The only simple way out of this is to delete the presumably-corrupt
> WAL log by running pg_resetxlog. That will destroy the evidence
I couldn't find it... mmm what a strange place for an executable:
/usr/lib/postgresql/8.3/bin/pg_resetxlog
> about what went wrong, though, so if you'd like to contribute to
> preventing such problems in future you need to save a copy of
> everything beforehand (eg, tar up all of $PGDATA). Also you might
> have a corrupt database afterwards :-(
What if I just don't care about recovery of *one* DB (that is maybe
the culprit) and just see the server restart then just do a restore
from a VERY recent backup?
Is there a way to just kill recovery for one DB? Just don't start it
at all?
This is the same DB having problem with recreation of gin index
BTW... and I've the feeling that the problem is related to that
index once more... I was vacuuming full, I aborted...
I think the DB is trying to recreate the index but due to some
problem (can I say bug or is it too early?) it segfaults.
I think this could be of some help:
2009-04-08 16:47:13 CEST LOG: database system was not properly shut
down; automatic recovery in progress
2009-04-08 16:47:13 CEST LOG: redo starts at 72/9200EBC8
BTW:
Linux amd64, debian stock kernel
Debian etch/backport: Version: 8.3.4-1~bpo40+1
Now let's learn how to use pg_resetxlog
thanks
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
