PostgreSQL ERROR: invalid memory alloc request size 18446744073709551613 SQL-состояние: XX000
Есть типовая база под замком, развернутая на потгресе под виндой.
Бэкап очень старый, но той же версии конфы, что сейчас на проде.
С недавних пор при обращении к одному из справочников вылетает ошибка ERROR: invalid memory alloc request size 18446744073709551613 SQL-состояние: XX000
Базу так же не выгрузить в дт средствами платформы и не бэкапнуть средствами pg.
Проблемная таблица в самом pg найдена (справочник Документы физ.лиц), но не поддается никаким действия с ней с той же ошибкой.
Подскажите, что можно сделать?
Очистка проблемного справочника и последующая очистка битых ссылок на него подойдет, т.к. справочник не критичен в данной конфе.
Но как к нему подступиться?
Бэкап очень старый, но той же версии конфы, что сейчас на проде.
С недавних пор при обращении к одному из справочников вылетает ошибка ERROR: invalid memory alloc request size 18446744073709551613 SQL-состояние: XX000
Базу так же не выгрузить в дт средствами платформы и не бэкапнуть средствами pg.
Проблемная таблица в самом pg найдена (справочник Документы физ.лиц), но не поддается никаким действия с ней с той же ошибкой.
Подскажите, что можно сделать?
Очистка проблемного справочника и последующая очистка битых ссылок на него подойдет, т.к. справочник не критичен в данной конфе.
Но как к нему подступиться?
Найденные решения
В общем, данная ситуация была решена следующим образом:
1. Была сделана резервная копия папки data
2. Проблемная таблица была удалена полностью дропом.
3. Проблемная таблица восстановлена чистая скриптом.
4. Из старого бэкапа универсальной выгрузки данные с ключами перекачены.
Пока полет нормальный.
Такой способ использовал, т.к. таблица критичных данных не содержала.
Т.е. не рекомендуется, естественно, к использованию в подобных случаях.
1. Была сделана резервная копия папки data
2. Проблемная таблица была удалена полностью дропом.
3. Проблемная таблица восстановлена чистая скриптом.
4. Из старого бэкапа универсальной выгрузки данные с ключами перекачены.
Пока полет нормальный.
Такой способ использовал, т.к. таблица критичных данных не содержала.
Т.е. не рекомендуется, естественно, к использованию в подобных случаях.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
, что можно удалить.
Там смысл в том, что ищется значение системного столбца ctid последней записи перед битой записью и по его значению+1 удаляется битая запись.
По крайней мере, попробовать можно.
Желательно сделать копию кластера. Остановить СУБД, скопировать всю папку data куда-нибудь и потом уже экспериментировать.
Там смысл в том, что ищется значение системного столбца ctid последней записи перед битой записью и по его значению+1 удаляется битая запись.
По крайней мере, попробовать можно.
Желательно сделать копию кластера. Остановить СУБД, скопировать всю папку data куда-нибудь и потом уже экспериментировать.
В общем, данная ситуация была решена следующим образом:
1. Была сделана резервная копия папки data
2. Проблемная таблица была удалена полностью дропом.
3. Проблемная таблица восстановлена чистая скриптом.
4. Из старого бэкапа универсальной выгрузки данные с ключами перекачены.
Пока полет нормальный.
Такой способ использовал, т.к. таблица критичных данных не содержала.
Т.е. не рекомендуется, естественно, к использованию в подобных случаях.
1. Была сделана резервная копия папки data
2. Проблемная таблица была удалена полностью дропом.
3. Проблемная таблица восстановлена чистая скриптом.
4. Из старого бэкапа универсальной выгрузки данные с ключами перекачены.
Пока полет нормальный.
Такой способ использовал, т.к. таблица критичных данных не содержала.
Т.е. не рекомендуется, естественно, к использованию в подобных случаях.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот