PostgreSQL reclamando sobre memória compartilhada, mas a memória compartilhada parece estar OK

Eu venho realizando um tipo de esquema intensivo, removendo e criando um servidor PostgreSQL, mas agora reclama ..

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

Mas o problema permanece se o PostgreSQL for reiniciado service postgresql restart, suspeito que max_locks_per_transaction não irá ajustar nada.

Estou um pouco afastado porque as listas de solução de problemas para esse erro não estão funcionando para mim.

MAIS INFORMAÇÕES 1409291350: Alguns detalhes estão faltando, mas mantenho o resultado principal do 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
fonte

Versão do PostgreSQL SELECT version()? Problema interessante ...

— Craig Ringer

"Eu suspeito que max_locks_per_transaction não sintonize nada." - Por que você suspeitaria disso? Você já tentou seguir a sugestão da dica?

— Josh Kupershmidt

Você já tentou seguir a sugestão da dica? Eu descomentei max_locks_per_transaction = 64 # min 10no /etc/postgresql/9.3/main/postgresql.conf até agora.

— 48347

O max_locks_per_transaction padrão é 64 para começar - descomentar essa linha não a alterou efetivamente.

— yieldsfalsehood

OK, um aumento efetivo para 128 resolveu o problema , permitindo que a operação continuasse.

— 48347

Seu comentário sobre criação e remoção intensiva e o aviso recebido sobre o aumento de max_locks_per_transaction sugerem que você está descartando e criando muitos objetos na mesma transação . Cada um desses resulta em um bloqueio, que requer uma pequena quantidade de memória compartilhada. Por esse motivo, max_locks_per_transaction limita o número de bloqueios que você pode reter em uma transação (para impedir que qualquer transação use toda a memória compartilhada).

Você pode aumentar um pouco esse limite (eu recomendaria não defini-lo arbitrariamente grande ou você se deparará com uma situação separada de ficar realmente sem memória compartilhada total) ou fará suas quedas e criará em lotes de transações ou em uma gota / criar por transação.

Edit: Aparentemente, eu estava errado sobre como funciona max_locks_per_transaction. Na documentação, o número total de bloqueios disponíveis é max_locks_per_transaction * (max_connections + max_prepared_transactions) - qualquer transação pode conter mais de max_locks_per_transaction, desde que o número de bloqueios mantidos em qualquer lugar seja menor que esse valor total.

— rendimento
fonte

Meu fluxo de trabalho inclui (1) descartar um esquema X, (2) descartar outro esquema Y e (3) restaurar X no nome do esquema Y. Como eu disse, até hoje estive várias semanas realizando essas atividades e hoje o passo (2) está falhando. O passo (2) consiste principalmente em DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA public, estas são as sentenças que lançam WARNING, ERROR e HINT.

— 48347

Dobrar o número máximo de bloqueios de 64 para 128 permitiu que o fluxo de trabalho continuasse. Ainda não recebi todos os documentos internos, mas acho que o comprometimento entre as sentenças DROP SCHEMA e CREATE SCHEMA terá um efeito de alívio semelhante.

— 48347

Agora percebo que há muitos dias recebo um pequeno aumento de esquema e esse problema corresponde perfeitamente a um desses pequenos aumentos de esquema . Como estratégia geral, terei mais consideração com as DICs a partir de agora.

— 48347