PostgreSQL жалуется на совместную память, но с общей памятью все в порядке

Я выполнял довольно интенсивное удаление и создание схемы на сервере PostgreSQL, но теперь жалуется ..:

WARNING:  out of shared memory
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

Но проблема остается, если PostgreSQL просто перезапустить service postgresql restart, я подозреваю, что max_locks_per_transaction ничего не настроит.

Я немного отчужден, потому что списки устранения неполадок для этой ошибки не работают для меня.

Дополнительная информация 1409291350: отсутствуют некоторые детали, но я сохранил основной результат SQL.

postgres=# SELECT version();
PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2,
 64-bit

И:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty

postgresql schema memory

— 48347
источник

Версия PostgreSQL от SELECT version()? Интересная проблема ...

— Крейг Рингер

«Я подозреваю, что max_locks_per_transaction ничего не настроит». - почему ты подозреваешь это? Вы пытались на самом деле следовать предложению подсказки?

— Джош Купершмидт,

Вы пытались на самом деле следовать предложению подсказки? Я max_locks_per_transaction = 64 # min 10пока не комментировал в /etc/postgresql/9.3/main/postgresql.conf.

— 48347

Максимальное значение по умолчанию max_locks_per_transaction - 64, раскомментирование этой строки не изменило ее.

— урожайность

Хорошо, эффективное увеличение до 128 решило проблему , фактически позволило продолжить работу.

— 48347

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

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

Изменить: Видимо, я был неправ о том, как работает max_locks_per_transaction. Согласно документации, общее количество доступных блокировок max_locks_per_transaction * (max_connections + max_prepared_transactions) - любая транзакция может содержать больше, чем max_locks_per_transaction, если количество блокируемых везде блокировок меньше этого общего значения.

— yieldsfalsehood
источник

Мой рабочий процесс включает в себя (1) сброс схемы X, (2) удаление другой схемы Y и (3) восстановление X по имени схемы Y. Как я уже говорил, до сегодняшнего дня я выполнял эти действия более нескольких недель, а сегодня шаг (2) не выполняется. Шаг (2) в основном состоит из DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA publicследующих предложений: «ПРЕДУПРЕЖДЕНИЕ», «ОШИБКА» и «СОВЕТ».

— 48347

Удвоение максимальных блокировок с 64 до 128 позволило продолжить рабочий процесс. Я еще не получил все внутренности, но я думаю, что фиксация между предложениями DROP SCHEMA и CREATE SCHEMA будет иметь аналогичное облегчающее действие.

— 48347

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

— 48347