Re: How to repair Pg 9.1?
От | Dmitry E. Oboukhov |
---|---|
Тема | Re: How to repair Pg 9.1? |
Дата | |
Msg-id | 20120415141603.GH5518@apache.rbscorp.ru обсуждение исходный текст |
Ответ на | Re: How to repair Pg 9.1? (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: How to repair Pg 9.1?
|
Список | pgsql-general |
>> 2012-04-15 16:46:02 MSK LOG: server process (PID 825) was terminated by signal 11: Segmentation fault ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> What can I do in the situation? > Well, what happened is quite clear. One of the processes was terminated > by the OOM killer. The database noticed this and responded properly by > restarting the database. That caused a proper recovery - you don't need > to "repair" the database. > What you need to do is change the machine configuration so that the OOM > errors do not happen. I don't know what's running on the machine, but > this usually means tweaking the vm.* parameters at the kernel level and > shared_buffers/work_mem/maintenance_work_mem at the PostgreSQL level. > In this particular situation (ALTER TABLE) I'd use a low value for the > maintenance_work_mem parameter - it'll run longer but won't need that > much memory. > Tomas I've just upgraded my postgresql upto current wheezy version (9.1.3-2/Debian): I wanted to get backtrace so it was upgraded when I installed postgresql-dbg package. After upgrading it discontinued segfault and began work fine. :) -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Вложения
В списке pgsql-general по дате отправления: