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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
