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
