| От | Bernd Helmle |
|---|---|
| Тема | standalone backend PANICs during recovery |
| Дата | |
| Msg-id | 00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan обсуждение исходный текст |
| Ответы |
Re: standalone backend PANICs during recovery
|
| Список | pgsql-hackers |
While investigating a problem on a streaming hot standby instance at a
customer site, i got the following when using a standalone backend:
PANIC: btree_xlog_delete_get_latestRemovedXid: cannot operate with
inconsistent data
CONTEXT: xlog redo delete: index 1663/65588/65625; iblk 11, heap
1663/65588/65613;
The responsible PANIC is triggered here:
src/backend/access/nbtree/nbtxlog.c:555
btree_xlog_delete_get_latestRemovedXid(XLogReaderState *record)
{
[...]
if (!reachedConsistency)
elog(PANIC, "btree_xlog_delete_get_latestRemovedXid: cannot operate with
inconsistent data");
[...]
}
There's already an "optimization" before, exiting with InvalidTransactionId
in case a HS doesn't count any active backends. In standalone mode however,
CountDBBackends() will always return 1 afaik. It looks like
btree_xlog_delete_get_latestRemovedXid() needs an additional check for
standalone backends, so i came up with the attached patch. This allowed the
standalone backend to recover without any problems.
--
Thanks
Bernd
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера