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
>
