Re: recovery after segmentation fault
От | Martijn van Oosterhout |
---|---|
Тема | Re: recovery after segmentation fault |
Дата | |
Msg-id | 20090408215942.GA11933@svana.org обсуждение исходный текст |
Ответ на | Re: recovery after segmentation fault (Ivan Sergio Borgonovo <mail@webthatworks.it>) |
Ответы |
Re: recovery after segmentation fault
Re: recovery after segmentation fault |
Список | 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.
Вложения
В списке pgsql-general по дате отправления: