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
|
| Список | 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 по дате отправления: