Давай таблицу чинить

Ошибки чтения таблиц все еще есть?

ага, multixactid — apparent wraparound

а битые туплы не могу удалить - ошибка attempted to delete invisible tuple

На какой конкретно записи падает?

Пробовал все записать нулями?

все эт как?

В смысле страницы испорченные

В смысле страницы испорченные

да это пройдено, в конфиге включил zero damaged pages

Ты не спеши

На какой записи падает запрос?

там в таблице comments примерно 3милл туплов с ненулевым xmax, и подозреваю что они ссылаются на трансакции которых давно нет, вот я в тупике тк не знаю как это вылечить

На какой записи падает запрос?

на какой конкретно не скажу, но ошибка timestamp out of range

давай так

это при попытке pg_dump

а бд изначально какой версии была ?

\set FETCH_COUNT 1 \pset pager off select ctid,colmn1,...,columnN from comments;

пробую удалить туплы с битыми таймштампами: elete from comments where date > '1 Jan 9999' or date < '1 Jan 2000' or date_found > '1 Jan 9999' or date_found < '1 Jan 2000'; но ошибка attempted to delete invisible tuple

\set FETCH_COUNT 1 \pset pager off select ctid,colmn1,...,columnN from comments;

давай так попробуй и напиши сюда на чем падает

а бд изначально какой версии была ?

9.5 ставил в начале октября из apt, наверное 9.5.5

давай так попробуй и напиши сюда на чем падает

ок сек

это не вот это случаем ? Preventing Transaction ID Wraparound Failures

это не вот это случаем ? Preventing Transaction ID Wraparound Failures

не, то в 9.4х был баг какой-то

хотя с с 9.5 это пофиксили

если БД изначально была на 9.5 то но деложно

Не упал еще?

Не упал еще?

не, я в tmux запустил и детачнулся, там очнь много на экран печатается

а БД с нуля делали на 9.5 или pg_upgrade ?

когда делал pg_dump, на 300м мегабайте дампа он отваливался

а БД с нуля делали на 9.5 или pg_upgrade ?

с нуля

о вот вылетело

ERROR: timestamp out of range

Может это битые данные, которые не приводятся в разумный timestamp?

Может это битые данные, которые не приводятся в разумный timestamp?

ну наверное иначе и быть не может

A vacuum какой-нибудь над таблицей проходит?

A vacuum какой-нибудь над таблицей проходит?

только vacuum, но не фулл

Это понятно

А vacuum freeze?

А vacuum freeze?

вот не знаю, могу попробовать

давай так попробуй и напиши сюда на чем падает

вот на этом отвалилось ERROR: timestamp out of range

а какое перед этим сообщение?

а ничего, просто данные в табличке

какая последняя страница?

вот, давай сюда

(92815,25) вот это может

да

SELECT ctid, * from comments;

готов расстатья с этими данными?

конечно!

напалмом

хоккей

SELECT ctid, column1...,columnN from comments where ctid='(92816,1)'; и т.д. ну и SELECT ctid, column1...,columnN from comments where ctid='(92816,2)'; и т.д. эта страница падает или нет?

ну значит и следующая испорчена

в общем понял, как найти испорченные страницы?

давай их затрем

с цифрой 4 ничего не возвращает

давай их затрем

ага, а как?

останови пг

done

а не, спот

нене, запусти обратно

ок запустил

посмотри как файл называется

на каком файле падает?

ээ а как это посмотреть?

в логе ничего нет?

ERROR: S client not available

если нет, то select relfilenode from pg_class where relname = 'comments';

в логе ничего нет?

это на запрос select ctid, * from comments where ctid='(92816,3)': 2016-12-14 18:42:31 EET [17076-1] postgres@vw WARNING: using index "pg_toast_2619_index" despite IgnoreSystemIndexes 2016-12-14 18:42:31 EET [17076-2] postgres@vw WARNING: using index "pg_toast_2619_index" despite IgnoreSystemIndexes 2016-12-14 18:42:31 EET [17076-3] postgres@vw ERROR: MultiXactId 3036690260 does no longer exist -- apparent wraparound 2016-12-14 18:42:31 EET [17076-4] postgres@vw STATEMENT: FETCH FORWARD 1 FROM _psql_cursor 2016-12-14 18:42:31 EET [17076-5] postgres@vw ERROR: current transaction is aborted, commands ignored until end of transaction block 2016-12-14 18:42:31 EET [17076-6] postgres@vw STATEMENT: CLOSE _psql_cursor

если нет, то select relfilenode from pg_class where relname = 'comments';

relfilenode 16443

посмотри еще oid бд

select oid,datname from pg_database;

oid такой же

а

16385

вот, где у тебя лежит файл 16385/16443 ?

sek

у тебя в таблице есть лобы?

/var/lib/postgresql/9.5/main/base/16385

у тебя в таблице есть лобы?

лобы эт что?

блобы?

LOB

есть туплы которые в тостах лежат

но про lob не слышал

хм, надо подумать

postgres@3081:~/9.5/main/base/16385$ ls -lah | grep 16443 | wc -l 110

я бы рекомендовал тебе перед затиркой страниц сделать копию всех касающихся к commets файлов

110 кусков этого файла 16443

вот, так надо как то посчитать

у меня места нет, но все диски отзеркалены в гуглохранилище, поэтому если что не так, восстановлю проделав все сначала

есть внешний медленный hdd, может туда pgdata перенесу?

это долго

вот, так надо как то посчитать

просто забить нулями чанки этого файла, в котором нечитающиеся туплы?

у тебя же есть несколько строк, перед тем как запрос упал?

у тебя же есть несколько строк, перед тем как запрос упал?

только одна с тем ctid (92816,1)

ладно, сейчас вычислим

по крайней мере попробуем

странно что это не автоматизировано еще

по идее 92816 должна быть в первом файле