а ну ок, я скрипт запустил, нашел уже штук 500 битых записей

Мне повезло, у меня было только 2. Удалил их. Всё заработало.

как вы умудрились тосты загосить!? диски сдохли?

у меня такое было когда alter был с добавлением столбца с дефолтным значением, и в это время закончилось место.

А вот кто-нибудь может сказать в чем заключались фиксы для постгреса под 1с ? или где почитать про это можно ?

(есть мысль что это может пригодиться и не в 1с)

на pgconf 2016 был доклад на эту тему.

https://pgconf.ru/2016/90069

там Федя Сигаев рассказывает про фиксы

спасиб!

как вы умудрились тосты загосить!? диски сдохли?

oom killer начал убивать процессы постгреса, после того как покончил с кривым скриптом питона. это мне хороший урок думать много раз прежде чем запускать фигню на сервере с бд

в документашке постгреса есть про ООМ sysctl -w vm.overcommit_memory=2

17.4.3. Чрезмерное выделение памяти в Linux

oom killer начал убивать процессы постгреса, после того как покончил с кривым скриптом питона. это мне хороший урок думать много раз прежде чем запускать фигню на сервере с бд

а разве WAL/VACUUM не должен это вычестить?

Анастасия ты как думаешь? Для меня такое поведение непонятно. Транзакция ведь в итоге не закоммичена.

Анастасия ты как думаешь? Для меня такое поведение непонятно. Транзакция ведь в итоге не закоммичена.

ты так говоришь, как будто pg работает в сферическом вакууме, а не на реальном железе и софте, в том числе и в ядре/модулях нет ошибок

меня всегда смешило отношение разработчиков PostgreSQL: ну а кто что-то без ведома pg может в PGDATA изменить.

меня всегда смешило отношение разработчиков PostgreSQL: ну а кто что-то без ведома pg может в PGDATA изменить.

разработчики базы данных не могут не верить файловой системе

так же, как они не могут не верить оперативной памяти

иначе им прийдется писать свою ОС с нуля, как сделали в mongo (последней это, кстати, не помогло)

именно поэтому oracle использует raw-девайсы? :)

:D

не верить не может, но должен быть готовым

именно поэтому oracle использует raw-девайсы? :)

подозреваю, что оракл использует raw-devices потому, что может.

ха прикольно, БД с интегрированной ОС

ха прикольно, БД с интегрированной ОС

монго. Яркие ощущения гарантирую

бывают даже процессоры с "поддержкой" sql ;) смотри oracle m7

Если писать как говорит Дима можно поднять надёжность процентов на 20-30 но при этом сильно понизив производительность и в несколько раз увеличив кодовую базу. Каждый должен заниматься своим делом.

а так да, кругом пони и смайлики и все хорошо

и fast food на каждом углу

быстро дёшево и... не шибко надёжно и вкусно это вполне конкретная потребность экономики. Я не говорю что нету другого подхода и областей... просто Postrges явно старается скорее быть на гране этого направления. ИМХО конечно

а так да, кругом пони и смайлики и все хорошо

это называется unix way в частности и слои абстракций в целом

те же mongo сделали свою ОС и запускают код в ней. Но сделана она ужасно а инструментов отладки там нет вовсе

zvercd из убунты чтоли сделали?

а разве WAL/VACUUM не должен это вычестить?

вакуум тоже падает с той же ошибкой

вакуум тоже падает с той же ошибкой

это не правильно

удачи!

спасибо ?

а разве WAL/VACUUM не должен это вычестить?

а если убился какой-нибудь процесс vacuum'a, или bgwriter'a/wall writer'a? Транзакция была закоммичена, просто данные корректно не сохранились. Тем более что в той ситуации, как я помню было fsync=off

и чексуммы выключены, скорее всего

fsync=off

fsync=off is web scale

fsync=off is web scale

mongo-style

mongo-scale

оракл рав девайс не особо развивает, в ASM пошел

Ну блин. Все битые туплы удалил, но трансфер таблицы снова зафейлился на том же pg_toast_16455: pg_dump: Dumping the contents of table "profiles" failed: PQgetResult() failed. pg_dump: Error message from server: ERROR: missing chunk number 0 for toast value 38645199 in pg_toast_16455 Нельзя никак найти oid/id тупла по toast id? Гугл говорит что только перебор, но он 9 часов занял в последний раз, и уже не знаю что делать...

а ты pg_dump в каком режиме запускаешь?

вот такой вот пайп pg_dump -d vw -O -t profiles -F c -v | ssh postgres@serveraddress "pg_restore -d vw"

А вот таким скриптом отбираю айдишники мертвых туплов: DO $f$ declare curid INT := 0; vcontent TEXT; badid INT; begin FOR badid IN SELECT id FROM profiles LOOP curid = curid + 1; if curid % 1000000 = 0 then raise notice '% rows inspected', curid; end if; begin SELECT profile INTO vcontent FROM profiles where id = badid; vcontent := substr(vcontent::text,1000,2000); exception when others then raise notice 'data for id % is corrupt', badid; continue; end; end loop; end; $f$;

но этот скрипт не помог как я смотрю?

т.е. в таблице нету тюплов с мёртвыми тостами, а pg_dump всёравно ругается?

я думаю лучше select *

т.к. ты отбираешь только один столбец в данных

а повреждения могут быть в других

ну он 1251 мертвую запись нашел, я сделал DELETE их по id, а pg_backup все равно крашится на том же toast id что и в первый раз. Дропнуть бы все записи которые в этом тост ид куски хранят, только вот как определить какие у них ид?

и может быть скажу ересь, но можно попробовать сдампить в plain формате... оно не должно тогда залезать никуда куда не нужно.

сделать скрипт где select * from profiles where id=по циклу

а ошибка точно та же, что и в первый раз? тоже pg_toast_16455?

я думаю лучше select *

ох точно, сейчас попробую. но другие колонки в записях только int и timestamp, не должны они в тупле храниться вроде

а ошибка точно та же, что и в первый раз? тоже pg_toast_16455?

угу

ох точно, сейчас попробую. но другие колонки в записях только int и timestamp, не должны они в тупле храниться вроде

а что id храниться ? ))

ох точно, сейчас попробую. но другие колонки в записях только int и timestamp, не должны они в тупле храниться вроде

ты хотел сказать в toast

а что id храниться ? ))

тьфу, в тосте

Рекламмный лозунг: "TOAST - Впихнём невпихуеммое!"

впихнём - вроде слитно пишеться ))

подумал что есть такое слово - пихнём

и невпихуемое - с одной "м" ))

а вот тут я хотел бы 10 м поставить

интересно вот - а если случится обратное - отвалится сам тупл, а его тосты останутся, тогда уже точно не получится вычислить такой тост и удалить его с диска?

можно, только руками придёться файлы ковырять

впихнём - вроде слитно пишеться ))

тся - ться :D

ага ))

жуть. следует наверное книжку какую про устройсто постгреса почитать или доки, полезно знать

жуть. следует наверное книжку какую про устройсто постгреса почитать или доки, полезно знать

Где-то встречал на просторах инета. Там разбирали по байтам содержимое файлов, заголовок и прочее.

для начала. уверены, что именно на той таблице проблемы ищете? with toast as (select oid from pg_class where relname = 'pg_toast_16455') select relname from pg_class where reltoastrelid = (select oid from toast);

для начала. уверены, что именно на той таблице проблемы ищете? with toast as (select oid from pg_class where relname = 'pg_toast_16455') select relname from pg_class where reltoastrelid = (select oid from toast);

у меня при таком запросе как раз падал ))

для начала. уверены, что именно на той таблице проблемы ищете? with toast as (select oid from pg_class where relname = 'pg_toast_16455') select relname from pg_class where reltoastrelid = (select oid from toast);

угу, я бекап только этой таблицы и переношу ?

запрос работает, таблица profiles

у меня при таком запросе как раз падал ))

при каком таком? при поиске в pg_class?

для начала. уверены, что именно на той таблице проблемы ищете? with toast as (select oid from pg_class where relname = 'pg_toast_16455') select relname from pg_class where reltoastrelid = (select oid from toast);

reltuples: 3.89846e+08 Это похоже все туплы которые в той базе есть. Что за фигня с названием pg_toast_16455? Я думал они секвенциально на куски как-то делятся...

откуда вообще интересно эта цифра 16455 взялась

это oid вашей таблички. pg_toast_'tableoid'

ох, теперь многое стало понятно

при каком таком? при поиске в pg_class?

ага

Если не бороться за "убитые" данные можно включить zero_damaged_pages

Если не бороться за "убитые" данные можно включить zero_damaged_pages

это где включается?

reltuples: 3.89846e+08 Это похоже все туплы которые в той базе есть. Что за фигня с названием pg_toast_16455? Я думал они секвенциально на куски как-то делятся...

select * from pg_class where relname = 'pg_toast_16455': а вот видимо reltuples: 9.39638e+06 которые слишком жирные чтоб поместиться в 8кб, да? Как бы id записей узнать отсюда, да перебирать только их?

Если не бороться за "убитые" данные можно включить zero_damaged_pages

а собирать из сорцов не нужно для этого?

а собирать из сорцов не нужно для этого?

не zero_damaged_pages = on достаточно

не zero_damaged_pages = on достаточно

окей, запустил снова c этим флагом

postgresql.conf

Возможно потребуется рестарт. Параметр описан в документации

А я все еще борюсь с мертвыми pg_toast, не могу из-за них перенести последнюю таблицу profiles на новый сервер, и крашится все на вот этом тосте: pg_toast_16455. Делал REINDEX pg_toast.pg_toast_16455, но не помогло. Теперь сделал VACUUM FULL profiles - вакуум только что завершился с той же ошибкой, с которой прерывается pg_dump: vw=# VACUUM FULL profiles; ERROR: missing chunk number 0 for toast value 38643697 in pg_toast_16455 Поможет ли pg_repack? Остается наверное написать скрипт с хандлингом exception для перебора каждой записи таблице, да?

pg_repack делает переливку таблицы простым SELECT