Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 Логика именах файлов в pg_xact и отсутствующий файл  [new]
SOM777
Member

Откуда:
Сообщений: 3
По неизвестной причине (ни ребутов, ни блэкаутов не было) - возникла проблема с базой:
Could not open file "pg_xact/0955": No such file or directory.

Как я понимаю не может найти один из файлов журнала метаданных транзакций.

Но если смотреть содержимое этого каталога, то в нем файлы от 0000, 0001, 0002 ... до ... 0099, при этом по дате создания 0099 самый свежий, между файлами нумерация не прерывается, по датам создания файлов совпадение есть, т.е. не похоже, что где-то что-то отсутствует.

В чем может быть проблема? Откуда мог появиться 0955 если максимальный по номеру 0099? 0099 создан сегодня и видно, что система продолжает в него запись.

В режиме ignore_system_indexes удалось получить доступ к базе, на первый взгляд содержимое в полном порядке. Однако pg_dump все равно не дает сделать, ссылаясь на отсутствие этого файла и перед этим "pg_dump: WARNING: using index "pg_toast_2618_index" despite IgnoreSystemIndexes".

Куда копать (кроме старого бэкапа)?
6 ноя 20, 21:00    [22227765]     Ответить | Цитировать Сообщить модератору
 Re: Логика именах файлов в pg_xact и отсутствующий файл  [new]
SOM777
Member

Откуда:
Сообщений: 3
If those clog numbers are not in your usual range, it usually means the
row is corrupt and is referring to an corrupt xid number, so the row is
bad, not the clog files are missing.

https://www.postgresql.org/message-id/alpine.GSO.2.01.0907231353180.6160@westnet.com

Есть какой-то способ восстановить корректное имя clog файла? Или единственный способ это "Generate a 256K file of all "55" characters, which indicates all transactions it might be looking for are treated as already commited"?
6 ноя 20, 21:30    [22227782]     Ответить | Цитировать Сообщить модератору
 Re: Логика именах файлов в pg_xact и отсутствующий файл  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
SOM777
If those clog numbers are not in your usual range, it usually means the
row is corrupt and is referring to an corrupt xid number, so the row is
bad, not the clog files are missing.

https://www.postgresql.org/message-id/alpine.GSO.2.01.0907231353180.6160@westnet.com

Есть какой-то способ восстановить корректное имя clog файла? Или единственный способ это "Generate a 256K file of all "55" characters, which indicates all transactions it might be looking for are treated as already commited"?


вам проще будет найти нужную поврежденную строку и удалить... так как если она битая то там не только xid битый а что угодно...
--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
6 ноя 20, 21:33    [22227786]     Ответить | Цитировать Сообщить модератору
 Re: Логика именах файлов в pg_xact и отсутствующий файл  [new]
SOM777
Member

Откуда:
Сообщений: 3
С pg_xact удалось разобраться.
Вылезли "ERROR: missing chunk number 0 for toast value 129731 in pg_toast_736955"

поиском по базе нашли проблемную таблицу и побитые текстовые поля (их не много, всего 5 полей в 5 записях из 1.5 млн), чтобы не дропать записи целиком, просто обнуляем проблемные поля, а дальше вопрос - делать vacuum analyze для проблемной таблицы или по аналогии с рекомендуемым pg_repack (http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html) сделать vacuum full в оффлайне?

Надо ли делать REINDEX для таблицы и для pg_toast, если да, то в какой последовательности?
11 ноя 20, 14:11    [22230131]     Ответить | Цитировать Сообщить модератору
 Re: Логика именах файлов в pg_xact и отсутствующий файл  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4396
SOM777
С pg_xact удалось разобраться.
Вылезли "ERROR: missing chunk number 0 for toast value 129731 in pg_toast_736955"

поиском по базе нашли проблемную таблицу и побитые текстовые поля (их не много, всего 5 полей в 5 записях из 1.5 млн), чтобы не дропать записи целиком, просто обнуляем проблемные поля, а дальше вопрос - делать vacuum analyze для проблемной таблицы или по аналогии с рекомендуемым pg_repack (http://www.databasesoup.com/2013/10/de-corrupting-toast-tables.html) сделать vacuum full в оффлайне?

Надо ли делать REINDEX для таблицы и для pg_toast, если да, то в какой последовательности?


достаточно просто vacuum full по таблице если можете себе позволить.



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
11 ноя 20, 18:58    [22230368]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить