2016-04-27 4 views
0

У меня есть запрос, который удаляет записи из очень большой таблицы с 30 миллионами записей. Я удаляю записи в небольших фрагментах, например 10k записей за одну небольшую операцию. Когда я запускал этот запрос 5 раз, он работал нормально.Блоки транзакций из операции удаления в postgresql. Бревна?

Но после этого он не выходит. Теперь он также не может удалить даже 10 записей. Возможно, я подозреваю, что он создал огромные журналы транзакций. Если это так, какой-то орган, пожалуйста, помогите мне в том, как очистить журналы транзакций? и если что-то, что мне нужно изменить с помощью моего запроса на удаление? Любой запрос, чтобы узнать размер журнала? Я использую Postgres 9.1

WITH ids_to_delete as(
    SELECT rh.dp_value_id 
    FROM raw_dp_links rh LEFT OUTER JOIN dp_values dp 
    ON rh.dp_value_id=dp.dp_value_id 
    where dp.dp_value_id is null 
    limit 10000 
    ) 
    delete from raw_dp_links where dp_value_id in (select dp_value_id from ids_to_delete) 
+2

Скорее всего, ваш запрос ждет блокировки. См. Здесь: https://wiki.postgresql.org/wiki/Lock_Monitoring Если размер сегментов WAL (в Postgres нет такой вещи, как «журнал транзакций») слишком велик, вы получите сообщение об ошибке –

+0

да вы правы, потому что, когда я перезапустил свой db, он работал нормально. Но почему блокировка приобретается в простой операции удаления? – SUDARSHAN

+1

Ваш оператор удаления не будет блокировать себя. Вероятно, у вас есть другие транзакции, которые изменяют эти строки. Или некоторые внешние ключи, в которых изменена таблица с привязкой. Прочитайте страницу вики и запустите инструкции, чтобы выяснить, что вызывает эти блокировки. Это невозможно сказать без дополнительной информации. –

ответ

0

Во-первых, журналы транзакций PostgreSQL в основном фактором при восстановлении (после сбоя питания или момент времени восстановления) или при выполнении репликации. Из-за того, как PostgreSQL обрабатывает дисковое хранилище, большие сегменты журналов от транзакций не будут иметь проблем. PostgreSQL использует таблицы кучи (не упорядоченные вокруг индексов) с асинхронной сборкой мусора (autovacuum), поэтому единственной точкой, где сегменты журналов являются проблемой, является транзакция фиксации.

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

+0

Хорошо, я думаю, что вы правы ... поэтому я могу запустить этот первый ALTER TABLE table_name DISABLE TRIGGER ALL; то я думаю, что это должно сработать. – SUDARSHAN

+0

Да, если вы это сделаете, вы получите эксклюзивный замок на столе во время своей записи, и никто другой не сможет написать. –