Добрый день, в одной из БД кластера разрушилась таблица pg_rewrite.

При подключнии к БД через pg_admin жалуется на блоки в этой таблицы.

REINDEX и VACUUM FULL по ней не проходят, с такимиже ошибками чтения блоков.




Что делать?

Как можно ее восстановить?

Бэкапов нет.

MelkijСиний Слон,

снимать дамп данных, импортировать в чистый кластер.
И проверить диски и память на исправность.


А скадите, можно ли все данные из нее удалить, затем заполнить данными с друй подобной БД другого сервера, заменив ev_class на нужный?

скадите = скажите

MelkijСиний Слон,

это часть системного каталога. Официально руками его изменять вообще нельзя и возникающие баги при ручных изменениях с системным каталогом могут вовсе не рассматриваться как баги.


Экспорт сделать не дает, ни целиком ни эксопрт одной таблицы.

Даже при селекте из pg_tables пишет ошибку чтения блока из таблицы pg_rewrite.





Еще попробовал файлы pg_rewrite заменить на пустые (все три файла) - все равно пишет ошибку и не дает сделать вакуум фулл.


Я в тупике

Подскажите, как можно эту таблицу очистить.

в общем, очистил ее делетом , убив все сессии.
Сделал ей вакуум фул что пересоздалась.


Но, сейчас не идет ни один запрос ни к какой таблице.







при этом:




И так с любой таблицей.

Maxim BogukСиний Слонв общем, очистил ее делетом , убив все сессии.
Сделал ей вакуум фул что пересоздалась.


Но, сейчас не идет ни один запрос ни к какой таблице.







при этом:




И так с любой таблицей.

Ну сделайте файл пустой base/16396/11113.
А вообще - после таких сбоев базу на реплику переключают или с base backup оживляют.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru


Так на любую таблицу жалуется, и oid разные. Так что нет смысла думаю.




Вообще странно что вся огромная БД рушится из-за одной мааааааленькой таблички

MelkijИ да, вам не нужен системный каталог. Спасайте свои собственные данные и импортируйте в чистый кластер после initdb. Системный каталог там будет свой и исправный.



Но как?

qwwqСиний Слонпропущено...




Но как?
перед тем как лезть грязными ногами в системный каталог даже колхозник догадался бы сделать файловую копию кластера

теперь видимо "никак"

кстати первым советом на поддержке было бы сделать копию, при отсутствии бекапов

усё таки системный каталог это не "таблички" для узеров или админов. и не таблички для бд--девов. разве что почитать допустимо. а писанина в них допускается только косвенная -- ддл-м. (он попутно много чо сделать должон)
или когда терять уже нечего


Работал бы каталог этот нормально - лезть бы не пришлось.

Что теперь делать? Почему постгрес такой ненадежный? Как уцелевшие данные вытаскивать?

Maxim Bogukсначала pg_dump
если он валится - то pg_dump потаблично нужные таблицы


Это все валится, уже писал в этой теме.

Maxim BogukPS: сколько лет работаю не помню побитых физически таблиц...



Может у вас просто реального опыта с постгрес мало?

https://yandex.ru/search/?text=postgresql could not read block in file&lr=2

Опертивно закрыли тему с явным косяком постгрес, однако... http://www.sql.ru/forum/1299369/kak-sdelat-bekap-tolko-sistemnogo-kataloga

KarbafosMaxim Bogukсколько лет работаю не помню побитых физически таблиц на нормальном рейде

какой рейд не нормальный в этом ключе?

Присоединяюсь к вопросу.

jan2aryСиний СлонОпертивно закрыли тему с явным косяком постгрес, однако... http://www.sql.ru/forum/1299369/kak-sdelat-bekap-tolko-sistemnogo-kataloga Вам правильно в той теме все сказали, и правильно тему закрыли. Не надо перекладывать свой "косяк", как вы изволите выражаться, на кого-то другого.

Вы, видимо, не работали с другими СУБД.


Косяки постгреса, из-за которых наступает писец:

1) файл pg_control при его повреждении писец. в говно-оракеле он дублируется, к примеру. Тут нет.

2) системный каталог. Отдельно не бэкапиться, отдельно не востанавливается. При повреждении одной из таблиц (не всех pg_ конечно, но многих) приходит писец.



Такие дела.

Тут сидят ребята из разработки постгресса, это им на заметку.