И еще вопросик: что за pg_toast_1265865 ? Такая шляпа привязалась

к временной таблице. Удаляли временную каскадно с этой. Могло повлиять?

Вот прямо любопытно, что означает это "каскадно" :)

delete temp.temp_table cascade

если бы ссылочная целостность - то конечно

pg_toast это хранилища для больших объектов других таблиц почитайте, в документации вроде все явно

По-моему, эта штука работает прозрачно и пользователь обычно их не видит примерно никогда. Слабо представляю себе некий констрейнт связывающий темповую таблицу и toast ( чужой? ).

Daniella Starchenko
смотрите. Было вот так. Я не вижу тут связей с це...

Не понял, чего я там должен увидеть :) Ещё раз: данные от реиндекса не пропадают. По-умолчанию удаление чего бы то ни было не логируется.

это скрины временной таблицы, которую удаляли каскадом) Просто не видно связей с целевой таблицей

А я говорю про эфемерные связи между темповой таблицей и чьим-то toast-ом.

Вы бы лучше подробнее объяснили, что там произошло, конкретно. Что такое "пропали данные" — таблица или какие-то rows? > причем, временная таблица и целевая, которая очистилась, в разных схемах Хмм... а какая это полная версия PostgreSQL (SELECT version();)?

Daniella Starchenko
удалились все данные из таблицы, но схема осталась...

Версия уже очень старая (я про minor), обновились бы. Но если это не bug, то, что касается ссылок между таблицами, есть ограничения на них между temporary и permanent, например: ERROR: constraints on permanent tables may reference only permanent tables Так что из какой конкретно таблицы удалились данные? Можете показать её \d+?

там была таблица в некоторой схеме cdm. Называлась таблица ma_offer. поля были такими же, как и во временной

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

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

Это зависит от того, временная эта таблица или нет. Если нет, то даже если логирование не настроено, можно полезть в WAL (pg_waldump). > Схема temp. Да показали бы Вы \d уже, и указали, в какой из этих таблиц удалились данные. Лично я даже этого так и не понял. ;)

Да пофиг, в принцыпе. Восстановить можно только из бэкапа или первички, с этим они, думаю, разберутся. А делать всякие forensic исследования и смотреть в остатние walы или файлы -- вот уж вряд ли, так что зачем воду в ступе толочь...

А вот автору вопроса — не пофиг: https://t.me/pgsql/322137 Хотят предотвратить повторение происшествия, я так думаю.

Чтобы предотвратить происшэствие ему, скорее всего, имеет смысл настраивать wal archive. И вот это был бы очень полезный совет. Заодно будет шанс в следующий раз понять, в какой момент что удалялось.

это не предотвращение, это действия по ускорению восстановления а чтобы предотвратить в будущем, нужно понять что именно произошло .. да и просто интересно )

На самом деле действительно что-то я жёстковато как-то сказал. Ну да, если человек хочет разобраться -- то имеет смысл остановить postgres, снять копию БД, а лучшэ -- жёсткого диска посекторно, снять копии всех клиентских логов, которые доступны (всякие psql, dbeaver, pgadmin обычно пишут некоторый history для своих нужд). Потом -- читать остатки WAL -- возможно (хотя и не очень вероятно), что там останутся обновления страниц, обновляющие записи, читать непосредственно файл базы -- возможно, что vacuum ещё не всё зачисти, читать индэксы -- хотя если там после был vacuum, то это в общем тожэ не очень полезно, читать расположэние файлов на диске -- возможно, удастся найти какие-то обрывки старых и wal или файлов и понять что в какой момент там было.