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