PostgreSQL se queja de memoria compartida, pero la memoria compartida parece estar bien

He estado realizando una especie de esquema intensivo de caída y creación en un servidor PostgreSQL, pero ahora se queja ...:

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

Pero el problema persiste si PostgreSQL se reinicia con service postgresql restart, sospecho que max_locks_per_transaction no ajustará nada.

Estoy un poco alejado porque las listas de solución de problemas para este error no me funcionan.

MÁS INFORMACIÓN 1409291350: Faltan algunos detalles pero mantengo el resultado principal de 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
fuente

¿Versión de PostgreSQL de SELECT version()? Problema interesante ...

— Craig Ringer

"Sospecho que max_locks_per_transaction no sintonizará nada". ¿Por qué sospecharías eso? ¿Has intentado realmente seguir la sugerencia de la pista?

— Josh Kupershmidt

¿Has intentado realmente seguir la sugerencia de la pista? He descomentado max_locks_per_transaction = 64 # min 10en /etc/postgresql/9.3/main/postgresql.conf hasta ahora.

— 48347

Para empezar, el valor predeterminado de max_locks_per_transaction es 64, sin comentar que esa línea no la cambió efectivamente.

— Rendimiento falsa

OK, un aumento efectivo a 128 resolvió el problema , en realidad permitió que la operación continuara.

— 48347

Su comentario sobre la caída y la creación intensivas y el aviso que recibió sobre el aumento de max_locks_per_transaction sugieren que está cayendo y creando muchos objetos en la misma transacción . Cada uno de esos resultados produce un bloqueo, que requiere una pequeña cantidad de memoria compartida. Debido a esto, max_locks_per_transaction limita el número de bloqueos que puede mantener dentro de una transacción (para evitar que cualquier transacción use toda la memoria compartida).

Puede aumentar ese límite un poco (recomendaría no establecerlo arbitrariamente grande o se encontrará con una situación separada de quedarse sin memoria compartida total) o hacer sus caídas y crearlas en lotes de transacciones o como una sola gota / crear por transacción.

Editar: Aparentemente me equivoqué sobre cómo funciona max_locks_per_transaction. Según la documentación, el número total de bloqueos disponibles es max_locks_per_transaction * (max_ connections + max_prepared_transactions): cualquier transacción puede contener más de max_locks_per_transaction, siempre que el número de bloqueos en todas partes sea inferior a este valor total.

— rendimiento
fuente

Mi flujo de trabajo incluye (1) volcar un esquema X, (2) soltar otro esquema Y, y (3) restaurar X en el nombre del esquema Y. Como dije, hasta hoy he pasado varias semanas realizando estas actividades, y hoy el paso (2) está fallando. El paso (2) consiste principalmente en DROP SCHEMA IF EXISTS public CASCADE; CREATE SCHEMA public, estas son las oraciones que arrojan la ADVERTENCIA, ERROR y SUGERENCIA.

— 48347

Duplicar los bloqueos máximos de 64 a 128 permitió que el flujo de trabajo continuara. Iv todavía no tiene todos los elementos internos, pero supongo que comprometerse entre el DROP SCHEMA y las oraciones CREATE SCHEMA tendrá un efecto de alivio similar.

— 48347

Ahora me doy cuenta de que muchos días obtengo un pequeño aumento de esquema, y este problema coincide perfectamente con uno de esos pequeños aumentos de esquema . Como estrategia general, tendré más consideración con HINT de ahora en adelante.

— 48347