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

Поиск
Список
Период
Сортировка
От Bjoern Metzdorf
Тема Re: process exited with status 11 after XLogFlush: request is not satisfied
Дата
Msg-id 035f01c1a9d2$43a81600$81c206d4@office.turtleentertainment.de
обсуждение исходный текст
Ответ на process exited with status 11 after XLogFlush: request is not satisfied  ("Bjoern Metzdorf" <bm@turtle-entertainment.de>)
Ответы Re: process exited with status 11 after XLogFlush: request is not satisfied  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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






В списке pgsql-general по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Shortening time of vacuum analyze
Следующее
От: Tom Lane
Дата:
Сообщение: Re: process exited with status 11 after XLogFlush: request is not satisfied