Re: process exited with status 11 after XLogFlush: request is not satisfied

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

In response to

Responses

Browse pgsql-general by date

  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