Re: recovery after segmentation fault

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Re: recovery after segmentation fault
Date: 2009-04-08 23:15:57
Message-ID: 20090409011557.3aa10960@dawn.webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 8 Apr 2009 23:59:43 +0200
Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:

> What might be easier is turning on core dumps (ulimit -S -c
> unlimited) and then start postgres and see if it drops a core

thanks.

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

bwaaa. That's a bit of a pain.

I'm trying to understand this a bit better...
I think nothing terrible really happened since:
a) the DB that has the higher write load was actually the one that
caused the problem and I restored from a backup.
b) the other DBs have some writes too... but the software using them
doesn't have any idea about transactions so it is built with atomic
statement in mind... No operation I can think of was writing in more
than one table and I'd think most (all?) the operations were atomic
at the statement level.

So if I lost some writes in logs for the other DBs... that shouldn't
be a problem, right? I just lost some data... not coherency? right?

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

I backed up all the data dir.
I'm currently transferring it to my dev box.
I've already the same DB... but it is on lenny.
And it never gave me a problem.
Version are slightly different anyway:

Version: 8.3.6-1 (working)
Version: 8.3.4-1~bpo40+1 (sometimes problematic[1])

8.4 is at the door... and the only choice I have to fix the problem
on that box is:
- upgrade to lenny
- build postgresql from source, that is going to be a maintenance
pain.

Could anything related to vacuum and/or gin index had been fixet
between 8.3.4 and 8.3.6?

I think that if I'll stick with some rituals I can live with it.
Avoid vacuum full when there is load and restart the server before
doing it.

[1] slow vacuum full and gin index update

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2009-04-08 23:38:10 Re: recovery after segmentation fault
Previous Message Bernard Barton 2009-04-08 23:08:02 Is it possible for PostgreSQL to support mmddyyyy date format?