PostgreSQL se plaint de la mémoire partagée, mais la mémoire partagée semble être OK

J'ai effectué une sorte de suppression et de création de schéma intensive sur un serveur PostgreSQL, mais se plaint maintenant ..:

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

Mais le problème persiste si PostgreSQL vient d'être redémarré service postgresql restart, je pense que max_locks_per_transaction ne réglera rien.

Je suis un peu éloigné parce que les listes de dépannage pour cette erreur ne fonctionnent pas pour moi.

PLUS D'INFO 1409291350: Certains détails manquent mais je garde le résultat SQL de base.

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

Et:

$ 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
source

Version PostgreSQL de SELECT version()? Problème intéressant ...

— Craig Ringer

"Je soupçonne que max_locks_per_transaction ne réglera rien." - euh, pourquoi suspecteriez-vous cela? Avez-vous essayé de suivre la suggestion de l'indice?

— Josh Kupershmidt du

Avez-vous essayé de suivre la suggestion de l'indice? Je n'ai pas max_locks_per_transaction = 64 # min 10commenté dans /etc/postgresql/9.3/main/postgresql.conf jusqu'à présent.

— 48347

La valeur par défaut max_locks_per_transaction est 64 pour commencer - le fait de ne pas commenter cette ligne ne l'a pas réellement modifiée.

— yieldsfalsehood

OK, une augmentation effective à 128 a résolu le problème , permettant en fait à l'opération de se poursuivre.

— 48347

Votre commentaire sur la suppression et la création intensives et l'avis que vous avez reçu concernant l'augmentation de max_locks_per_transaction vous indiquent que vous supprimez et créez de nombreux objets dans la même transaction . Chacun de ces résultats dans un verrou, qui nécessite chacun une petite quantité de mémoire partagée. Pour cette raison, max_locks_per_transaction limite le nombre de verrous que vous pouvez détenir dans une transaction (pour empêcher une transaction d'utiliser toute la mémoire partagée).

Vous pouvez soit augmenter légèrement cette limite (je vous déconseille de la fixer arbitrairement ou vous vous retrouverez dans une situation distincte de manque de mémoire partagée totale), soit faire vos suppressions et créer soit par lots de transactions ou en une seule suppression / créer par transaction.

Edit: Apparemment, je me trompais sur le fonctionnement de max_locks_per_transaction. D'après la documentation, le nombre total de verrous disponibles est max_locks_per_transaction * (max_connections + max_prepared_transactions) - toute transaction peut contenir plus de max_locks_per_transaction, tant que le nombre de verrous détenus partout est inférieur à cette valeur totale.

— rendement
source

Mon flux de travail comprend (1) le vidage d'un schéma X, (2) la suppression d'un autre schéma Y et (3) la restauration de X sur le nom du schéma Y. Comme je l'ai dit, jusqu'à aujourd'hui, j'ai effectué plusieurs semaines ces activités, et aujourd'hui l'étape (2) échoue. L'étape (2) consiste principalement en DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA public, ce sont les phrases lançant l'AVERTISSEMENT, l'ERREUR et le CONSEIL.

— 48347

Le fait de doubler le nombre maximal de verrous de 64 à 128 a permis au workflow de continuer. Iv n'a pas encore tous les éléments internes, mais je suppose que commettre entre les phrases DROP SCHEMA et CREATE SCHEMA aura un effet de soulagement similaire.

— 48347

Maintenant, je me rends compte plusieurs jours que j'obtiens une petite augmentation de schéma, et ce problème correspond parfaitement à l'une de ces petites augmentations de schéma . En tant que stratégie générale, j'aurai dorénavant une plus grande considération avec les HINT.

— 48347