Re: recovery after segmentation fault

Поиск
Список
Период
Сортировка
От Ivan Sergio Borgonovo
Тема Re: recovery after segmentation fault
Дата
Msg-id 20090409011557.3aa10960@dawn.webthatworks.it
обсуждение исходный текст
Ответ на Re: recovery after segmentation fault  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On Wed, 8 Apr 2009 23:59:43 +0200
Martijn van Oosterhout <kleptog@svana.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


В списке pgsql-general по дате отправления:

Предыдущее
От: Chris
Дата:
Сообщение: Re: Table has 22 million records, but backup doesn't see them
Следующее
От: Bernard Barton
Дата:
Сообщение: Is it possible for PostgreSQL to support mmddyyyy date format?