Re: vacuum: out of memory error

From: Jakub Ouhrabka <kuba(at)comgate(dot)cz>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-general(at)postgresql(dot)org
Subject: Re: vacuum: out of memory error
Date: 2006-11-28 13:40:10
Message-ID: 456C3C3A.8080604@comgate.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks for the responses!

One thing I've forgotten: it's not reproducible. I can issue vacuum
command manually without any problems few minutes/seconds after seeing
the error message "out of memory" in the server log.

I also can't find any corrupted rows manually.

And for the listen/notify problem - it narrowed down to be our software bug.

So I've got "vacuum: out of memory" in server log from time to time and
no other symptoms.

> That can also be caused by setting maintenance_work_mem too high for
> what your hardware is capable of, though I agree that given the other
> problems it's likely that there is some kind of corruption.

maintenance_work_mem = 256000

There are 4G of RAM and 4G swap.

There's always:

ERROR: out of memory
DETAIL: Failed on request of size 262143996

256000 (work_mem in kb) * 1024 = 262144000

What is the cause of the error? Continuous block of this size can't be
allocated?

So maybe there's no corruption - what do you think?

Regards,

Kuba

Andrew Sullivan napsal(a):
> On Fri, Nov 24, 2006 at 11:59:16AM +0100, Jakub Ouhrabka wrote:
>> I've done little research in mailing list archives and I found possible
>> cause: table corruption caused by flaky hardware. Does it sound about
>> right? Are there any other possible causes?
>
> It sounds about right, yes; but the other possible cause is a
> software bug. In the absence of data proving you have no hardware
> problems, though, I think you'll find that people are singularly
> unwilling to investigate software bugs in this case.
>
>> What can be corrupted?
>
> Anything.
>
>> How can I check it?
>
> You can try stepping through the table in question and seeing if you
> run into problems anywhere. By binary search, you should be able to
> narrow it pretty quickly.
>
>> How can I correct it?
>
> Well, the corrupt rows are lost. The usual method is "restore from
> backup".
>
>> What
>> are possible consequences of this corruption?
>
> You can't read the data. But you already knew that: it's why your
> vacuum is blowing up.
>
> A
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-11-28 14:01:55 Re: IN clause
Previous Message Daniel Serodio 2006-11-28 13:34:39 Re: IS it a good practice to use SERIAL as Primary Key?