Re: How to repair Pg 9.1?

On 15.4.2012 16:16, Dmitry E. Oboukhov wrote:
>>> 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.
> :)

I haven't noticed it was a segfault - I kinda believed you it actually
was an OOM kill, but that does not cause segfaults. That's a whole
different story ...

It you were getting that whenever you run the ALTER TABLE and it stopped
after upgrading to 9.1.3, then there was something wrong in the version
you've been using before and it got fixed in 9.1.3. Or maybe it still
exists but it does not happen so often.

It'd be nice to know what version were you using and a detailed
description of what you've done - table structure, size, exact ALTER
TABLE command etc.

Tomas