From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it> |
Cc: | pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: recovery after segmentation fault |
Date: | 2009-04-08 21:59:43 |
Message-ID: | 20090408215942.GA11933@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-04-08 22:07:28 | Re: Are there performance advantages in storing bulky field in separate table? |
Previous Message | Robert Treat | 2009-04-08 21:06:44 | Re: Are there performance advantages in storing bulky field in separate table? |