Re: process exited with status 11 after XLogFlush: request is not satisfied
В списке pgsql-general по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: process exited with status 11 after XLogFlush: request is not satisfied |
| Дата | |
| Msg-id | 24081.1012409409@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: process exited with status 11 after XLogFlush: request is not satisfied ("Bjoern Metzdorf" <bm@turtle-entertainment.de>) |
| Список | pgsql-general |
"Bjoern Metzdorf" <bm@turtle-entertainment.de> writes:
> (gdb) bt
> #0 0x08066109 in nocachegetattr ()
> #1 0x080c0bfc in ExecEvalVar ()
> #2 0x080c16bb in ExecEvalExpr ()
> #3 0x080c179d in ExecEvalExpr ()
> #4 0x080c10c8 in ExecEvalFuncArgs ()
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.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера