Re: recovery after segmentation fault - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: recovery after segmentation fault
Date
Msg-id 20090408215942.GA11933@svana.org
Whole thread Raw
In response to Re: recovery after segmentation fault  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Responses Re: recovery after segmentation fault
Re: recovery after segmentation fault
List pgsql-general
On Wed, Apr 08, 2009 at 05:24:08PM +0200, Ivan Sergio Borgonovo wrote:
> How on Debian?
> Debian does all it's automagic stuff in init. I never learned how to
> start pg manually.

What might be easier is turning on core dumps (ulimit -S -c unlimited)
and then start postgres and see if it drops a core dump, which you can
then feed to gdb.

All the binaries are in /usr/lib/postgresql/8.3/bin/ (Debian supports
parallel installs of multiple versions of postgres).

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

Unfortunatly, the XLOG is shared betweens all databases on one cluster.

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

Interesting, hope you can get a good backtrace.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Attachment

pgsql-general by date:

Previous
From: Robert Treat
Date:
Subject: Re: Are there performance advantages in storing bulky field in separate table?
Next
From: Sam Mason
Date:
Subject: Re: Are there performance advantages in storing bulky field in separate table?