Re: variable que define "idle in transaction"

From: "Miguel Beltran R(dot)" <yourpadre(at)gmail(dot)com>
To: Lista PostgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: variable que define "idle in transaction"
Date: 2013-11-12 16:09:25
Message-ID: CAEc04cob8s2TxwmjVObmnynpFi0fshYUgBJCQ2hO=FDpe3KV4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Ahora que si quieres arriesgarte a otros posibles errores por forzar el
cierre de la transacción, agrega (1) SET AUTOCOMMIT = ON en las opciones
del usuario que se conecta a la BD.

Pero como dicen, lo mejor es que los programadores cierran la conexión.
Esto lleva a otra pregunta ¿con qué programan? porque creo recordar que
algunos frameworks u otras herramientas abren las conexiones y activan la
transaction

(1) http://www.postgresql.org/docs/9.1/static/ecpg-sql-set-autocommit.html

El 11 de noviembre de 2013 11:51, Fernando Hevia<fhevia(at)gmail(dot)com> escribió:

> Hola José,
>
> Perdoname pero el planteo es absurdo. Las transacciones Idle in
> Transaction se refiere a sesiones donde se inició una transacción y en ese
> momento dado el usuario o aplicación no está ejecutando nada contra la
> base. Puede deberse a que la aplicación está a la espera de que complete
> otra operación (ej: input del usuario, consulta leeenta a otra base,
> cálculo gigantoide, etc.), pero por lo general denota un ERROR DE
> PROGRAMACION. Lo normal es buscar los datos requeridos primero, abrir luego
> la transacción, actualizar la base y cerrar la transacción. Los últimos 3
> pasos debieran ocurrir en pocos milisegundos y nunca depender de un input
> externo que pudiese potencialmente frenar esta secuencia.
> Si un idle en transaction se extiende por más de algunos breves segundos
> ya puede ser un potencial problema a observar.
>
> En definitiva, la pelota del problema está en cancha de los programadores.
> Esto trasciende el reiterado conflicto DBA-Programadores. La solución aquí
> es programar correctamente esa parte de la aplicación y cualquier otra
> solución por fuera sólo tiene mérito si no tienes acceso al código.
>
> Saludos,
> Fernando.
>
>
>
>
>
> 2013/11/11 Gilberto Castillo <gilberto(dot)castillo(at)etecsa(dot)cu>
>
>>
>>
>> > Hola Gilberto,
>> >
>> > Los desarrolladores viven en una especie de paraiso donde no pueden ser
>> > interrumpidos por simples mortales..;-)
>> > Por eso debemos resolver el problema de conexiones idle a nivel de
>> > Postgre y servidor. Para desarrollar una idea necesitamos saber (si es
>> > posible..claro esta) cuál es(son) la(s) variable(s) que determinan que
>> > un proceso en el backend pasa a ser idle transaction. Se entiende?
>>
>> Eso es sencillo desde que el aplicativo accede hacer algo en la data,
>> Ver:
>> select * from pg_locks --que esta boqueado
>> SELECT procpid, current_query FROM pg_stat_activity --que operaciones se
>> esta realizando.
>>
>>
>> Ahora si quieres terminar las transacciones pasado cierto tiempo hay
>> variables para ello, pero eso puede provocar mala cara entre esos
>> inmortales :-))))).
>>
>>
>>
>> Saludos,
>> Gilberto Castillo
>> La Habana, Cuba
>>
>> ---
>> This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE
>> running at host imx3.etecsa.cu
>> Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com
>> >
>>
>> -
>> Enviado a la lista de correo pgsql-es-ayuda (
>> pgsql-es-ayuda(at)postgresql(dot)org)
>> Para cambiar tu suscripción:
>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>>
>>
>

--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alejandro Esperon 2013-11-12 16:50:04 Balanceo de carga
Previous Message Roberto Andrade Fonseca 2013-11-11 21:56:31 Programa de conferencias y talleres de la 1a Reunión de PostgreSQL y Linux del Bajio, Gdl., México