From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: process exited with status 11 after XLogFlush: request is not satisfied |
Date: | 2002-01-30 21:20:21 |
Message-ID: | 26202.1012425621@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> writes:
> It all looked good, but no, the problem persists.
> 5 minutes ago I did a
> "select ctid,* from table order by id limit 82000"
> and it worked flawlessly.
> Then I did a
> "select ctid,* from table order by id limit 200000"
> and it crashed again.
> I again tried
> "select ctid,* from table order by id limit 82000"
> and it crashed here also.
> What do you suspect here? Hardware failure?
Given the above facts, that's what I suspect. You may have something
like a disk controller that sometimes passes bad data. Or a bad RAM
chip that sometimes drops bits. If it weren't a flaky-hardware kind
of thing I'd expect the results to be reproducible.
> I ran a badblocks read-only test
> and it was fine. I tested memory with memtester and it was fine...
Can anyone suggest other diagnostic tools to try? I don't think either
of the above tests would be likely to notice a disk controller that
sometimes returns wrong data, for example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Reyes | 2002-01-30 22:12:53 | Re: Shortening time of vacuum analyze |
Previous Message | Bjoern Metzdorf | 2002-01-30 21:08:28 | Re: process exited with status 11 after XLogFlush: request is not satisfied |