1073741824
CONTEXT: SQL statement "SELECT pg_notify('transactions_log_insert', CAST(NEW.id AS TEXT))"
PL/pgSQL function public.transactions_log_insert() line 3 at PERFORM
Что ему не нравится?
work_mem = 1,5 Gb
Куда можно копнуть еще?
Операция возникновения ошибки - восстановление из бэкапа, psql
Уменьшыть work_mem. Я, правда, непонимаю -- зачем и почему при восстановлении дампа появляются pg_notify какие-то? Там триггеры что ли какие-то выполняются в процэссе? Отключать хорошо бы временно их выполнение.
Т.е. снизить work_mem с 1.5Гб до 512 хотя бы - норм будет? - Но почему, он же говорит, что ему 1.074 Мб надо, если я правильно понимаю суть ошибки Можно, пожалуйста, подробнее про триггеры?
Сразу до 64. Но не уверен вообще, что поможэт. Если notify накапливаются только в памяти, и никогда не выгружаются на диск (я не знаю, так ли это, надо в коде смотреть) -- то на work_mem ему плевать будет, оно всё равно весь объём таблицы закинет в очередь notify. А про триггеры -- смотрите, откуда они там берутся. Точнее -- откуда вообще какое-то выполнение какого-то notify. По идее -- все триггеры восстанавливаются в концэ дампа. Можэт, от старой какой-то базы остались.
В самом бекапе нет ошибок? Можно ли при восстановлении данных отключить уведомления notify и попробовать восстановить так?
В самом бэкапе нет ошибок, сначала бэкап схемы, а потом данные. Все обезличено. Наверное можно, но как?)
В смысле -- разными файлами бэкап схемы и данных? Тогда вот тут вы и встряли. Но, в общем, фигурно всё порезать -- невелика проблема. Установку триггеров в конец данных перенести.
Если эти уведомления лежат в триггерах, то таким образом: https://stackoverflow.com/questions/3942258/how-do-i-temporarily-disable-triggers-in-postgresql Если это просто в какой-то из процедур, то смотреть код в них.
Ого! Про session_replication_role не знал.
Я тоже, но я имел в виду обычный ALTER TABLE из ответа ниже, хотя и это, должно быть, будет работать.
Да, База среднего размера. Поэтому сначала обезличенную схему, а потом обезличенные данные. Вот такая идея залива
А вот можно по - подробнее, пожалуйста, про перенос установки триггеров в конец? Это в структурном бэкапе или с данными уже?
будете данные поверх индексов и форейнкеев заливать, будет медленно, много ИО, много wal и надо будет соблюдать порядок таблиц или отключать форейнкеи
Да в любом. Точнее, нет, наоборот -- дажэ если структурный, то перегнать сначала в плоский файл. Отрезать от схемы CREATE TRIGGER в отдельный файл любым редактором, выполнить потом оба файла подряд -- с заливкой и с CREATE TRIGGER.
Обсуждают сегодня