From: | Rensi Arteaga Copari <rarteaga(at)ende(dot)bo> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: fatal out of shared memory postgres |
Date: | 2010-09-27 19:50:19 |
Message-ID: | 4CA0F57B.2030107@ende.bo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El 27/09/2010 15:01, Alvaro Herrera escribió:
> Excerpts from Rensi Arteaga Copari's message of lun sep 27 14:58:23 -0400 2010:
>
>> Te comento también que la cantidad de la variable max_connections de
>> 100 a 200 y el problema no volvió aparecer en los últimos dos días.
> Eso es porque el total de espacio destinado a locks es
> max_connections * max_locks_per_transaction. Aumentando cualquiera de
> los dos tienes más espacio disponible para candados. Si volvieras
> max_connections a 100 y aumentaras max_locks_per_transaction al doble,
> deberías ver el mismo efecto.
>
> Supongo que el problema real es que haya una cantidad tan grande de
> candados tomados. Quizás sea un bug en la aplicación. Examina pg_locks
> a ver si hay algo fuera de orden.
>
Tienes alguna referencia o manual que me ayude a revisar
esto que sugieres de pg_locks, no se como fucniona.
En los procedimientos almacenados que tenemos no usamos el bloqueo de
tablas.
Si se utilizan bloqueos seguramente solo son los que el SGDB pone por
defecto
--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520317 - 4120900
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.
From | Date | Subject | |
---|---|---|---|
Next Message | Perla | 2010-09-27 21:04:15 | insertar desde archivo un dato date que es vacio |
Previous Message | Lennin Caro | 2010-09-27 19:11:43 | Re: Cargar datos como fecha |