From: | "Bjoern Metzdorf" <bm(at)turtle-entertainment(dot)de> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:08:28 |
Message-ID: | 035f01c1a9d2$43a81600$81c206d4@office.turtleentertainment.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
> Yeah, that does look like a corrupted-data problem. If you wanted to
> rebuild with debugging symbols turned on, it might be possible to
> extract the location of the bad tuple directly from the corefile.
> Short of that, what I'd do is find out what query the backend is
> crashing on (turn on debug query logging), and then investigate the
> tables involved using queries like "select ctid,* from foo limit N".
> By varying the limit you can home in on just where the bad tuple is.
I tried the "select ctid,* from table limit N"-way and found some possible
corrupted ctid. I then deleted all tuples in this ctid manually.
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? I ran a badblocks read-only test
and it was fine. I tested memory with memtester and it was fine...
How can this kind of corruption happen at all? And what can I do next?
greetings,
Bjoern
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-30 21:20:21 | Re: process exited with status 11 after XLogFlush: request is not satisfied |
Previous Message | Andrew Sullivan | 2002-01-30 20:47:14 | Re: Shortening time of vacuum analyze |