Locks.. encontrar el origen o culpable..

From: Andrés P(dot)P(dot) <solopostgres(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Locks.. encontrar el origen o culpable..
Date: 2010-07-02 20:15:04
Message-ID: AANLkTikv-y2ImshY2NNgoflUBfIllV0DJCLuUzI6KciT@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Estimados listeros

Tenemos un Server con postgres , dedicado, y con baja carga y hace unos días
se presentó una situación que ya se había presentado en Diciembre pasado y
que entonces abordamos parcialmente (osea..le dimos un placebo al cliente ya
que nuestras sospechas iban contra él, pero no pudimos demostrarlo).

La situación… Bajo desconocidas circunstancias se están generando
bloqueos en una tabla de la BD que terminan finalmente por botar la
aplicación que trabaja sobre ésta. No tengo una configuración de log
detallado pero en las dos ocasiones ha aparecido el texto “Ya existe una
transacción en curso” en el mismo momento del problema…… hasta lo que sé
este warning representa un error en algún código que no está cerrando
sesiones correctamente y seguramente por ahí está quedando algún lock
tomado.

En fin, los procedimientos de la BD son sencillísimos y sólo en uno de ellos
se tiene un bloque con Select FOR Update ya que existe una pequeña
posibilidad de que un proceso asíncrono con la lectura del dato lo pudiera
modificar antes o concurrentemente….. Los desarrolladores de la aplicación
sólo ejecutan los procedimientos almacenados (no tienen código SQL en
bruto)….. asi que nuestra sospecha del causante de esa sesión mal cerrada va
por una conección del cliente que usa un “motor connect driver db:psql” (que
ni conozco) y a través del cual ejecutan una sentencia de tipo Select…… (
tengo entendido que un select también puede generar Locks en ciertas
circunstancias).

Mi intención es aumentar los niveles del Log de postgres y también colocar
via crontab alguna Query para sacar una foto cada x minutos de tal forma de
encontrar si nuestra sospecha es real...lo justo y necesario para esa
finalidad sin que esto implique un costo alto en performance. Los parámetros
que se me ocurre modificar son log_min_messages y log_min_error_statement
dejarlos en nivel notice… especificar una duración para
log_min_duration_statement… habilitar log_connections, log_hostname..
configurar el log_line_prefix… otro que creo debo modificar es
log_lock_waits.. pero está asociado a deadlock_timeout y por ahí me enredo
en el sentido de afectar o registras cosas de más…….en fin, son sólo
nociones para hacer cambios .. por eso prefiero que alguien mas
experimentado me pueda apoyar en esto…..

Adjunto la sección LOGGING de mi postgresql.conf que actualmente está en
producción para que me indiquen donde modificar…. Y lo otro que necesito
es tener una Query que me entregue información del estado de la DB y los
eventuales locks cada x minutos para complementar lo del Log… me imagino
que sería una combinación entre pg_locks, pg_stat_activity…..o las funciones
pg_stat_get_backend_xxxx… yo tengo los usos de éstas en querys
individuales, pero no se si exista otra o algo más integral para mis fines….

Si estiman que debo considerar otros parámetros además del logging no duden
en indicármelo.

Bueno.. eso…Perdonen lo extenso… me gusta dar los detalles de los contextos
que planteo..

Saludos

Andrés

Attachment Content-Type Size
Postg_log.conf.txt text/plain 6.6 KB

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2010-07-02 23:35:46 Re: Locks.. encontrar el origen o culpable..
Previous Message Mariano Reingart 2010-07-02 19:30:35 Re: acceso desde pgadmin