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 = 262144000What 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
