Conexión se pierde.

From: angel Iracheta <angel(dot)iracheta(at)gmail(dot)com>
To: PostgreSQL Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Conexión se pierde.
Date: 2011-05-27 02:07:53
Message-ID: BANLkTikPX9NMG=5OcATtV+iDwtprfGJ9yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola a todos,

Tengo una aplicación en Visual Fox que se conecta a una base de datos en
Postregsql 8.20, que está alojada en un servidor Debian.

Pero tengo un problema desde que se migró la base de datos de la versión
8.12 a la 8.20, ya que al parecer las conexiones se están perdiendo, pero
permítanme darles más detalles:

1. La aplicación se conecta a Postgre por ODBC.

2. No tengo una conexión permanente cuando el usuario se logea en la
aplicación, sino que el código en toda la aplicación se conecta y se
desconecta de Postgre según se necesite.

3. Entonces cuando el código se intenta conectar a la base de datos, el ODBC
regresa un "handle" positivo si la conexión fue exitosa, pero si el "handle"
es negativo,
el código envía una alerta indicando que no fue posible la conexión a
Postgre.

4. Y desde que se migró la base de datos a la versión 8.20, empezamos a
notar que la aplicación notificaba que no había conexión a la base de datos,
pero estas notificaciones no tienen
ningún patrón especifíco, o sea puede pasar en cualquier pantalla, a
cualquier hora, con cualquier equipo y con cualquier usuario. De hecho ni
siquiera en la frecuencia hay un patrón,
pueden llegar 3 alertas en un día, 8 alertas en otro, o hay días que no hay
alertas.

5. Lo que es raro, es que si el usuario cierra la pantalla y la vuelve a
ejecutar, de inmediato puede trabajar normalmente, al menos hasta ahorita no
se ha presentado el caso de que el error
esté insistente con un medio ambiente en específico, que es a lo que me
refiero en el punto 4.

6. Por lo tanto habilité en el log del servidor los parámetros:
Log_connections, Log_disconnections y Log_line_prefix, para que al momento
de que pasar un evento,
poder rastrear en el log el ciclo de vida de la sesión.

7. Les muestro un ejemplo del log de uno de estos eventos:

<192.168.1.131(1898) | 2011-05-26 19:20:14.908 CDT | 17266 | | 0>LOG:
connection authorized: user=usuarios database=rq
<192.168.1.131(1898) | 2011-05-26 19:20:14.917 CDT | 17266 | | 0>LOG:
disconnection: session time: 0:00:00.009 user=usuarios database=rq
host=192.168.1.131 port=1898
< | 2011-05-26 19:20:14.918 CDT | 17267 | | 0>LOG: connection received:
host=192.168.1.131 port=1899
<192.168.1.131(1899) | 2011-05-26 19:20:14.919 CDT | 17267 | | 0>LOG:
connection authorized: user=usuarios database=rq
<192.168.1.131(1899) | 2011-05-26 19:20:14.928 CDT | 17267 | | 0>LOG:
disconnection: session time: 0:00:00.009 user=usuarios database=rq
host=192.168.1.131 port=1899
< | 2011-05-26 19:20:19.856 CDT | 17268 | | 0>LOG: connection received:
host=192.168.1.131 port=1901
<192.168.1.131(1901) | 2011-05-26 19:20:19.856 CDT | 17268 | | 0>LOG:
connection authorized: user=usuarios database=rq
<192.168.1.131(1901) | 2011-05-26 19:20:19.862 CDT | 17268 | |
27981283>ERROR: syntax error at or near "WCURSOR" at character 191
<192.168.1.131(1901) | 2011-05-26 19:20:19.862 CDT | 17268 | |
27981283>STATEMENT: Select
pgmail('tsolis(at)rq(dot)com','<errores(at)rq(dot)com>','Error!','26/05/2011
07:20:01 PM - EQ-MTTO # JEFE_MTTO

Error de Ejecucion: (12) No se encuentra la variable 'WCURSOR'.

Linea: SELECT Cur_reac

Numero de linea: 18

Programa: MTTO_OT_COTIVO_PCLAVE.CBO_COMO.INIT

')

< | 2011-05-26 19:20:21.544 CDT | 17269 | | 0>LOG: connection received:
host=192.168.1.131 port=1902
<192.168.1.131(1902) | 2011-05-26 19:20:21.545 CDT | 17269 | | 0>LOG:
connection authorized: user=usuarios database=rq
<192.168.1.131(1902) | 2011-05-26 19:20:21.667 CDT | 17269 | | 0>LOG:
disconnection: session time: 0:00:00.122 user=usuarios database=rq
host=192.168.1.131 port=1902
<192.168.1.131(1901) | 2011-05-26 19:20:21.667 CDT | 17268 | | 0>LOG:
disconnection: session time: 0:00:01.811 user=usuarios database=rq
host=192.168.1.131 port=1901
< | 2011-05-26 19:20:21.674 CDT | 17277 | | 0>LOG: connection received:
host=192.168.1.131 port=1903
<192.168.1.131(1903) | 2011-05-26 19:20:21.675 CDT | 17277 | | 0>LOG:
connection authorized: user=usuarios database=rq
<192.168.1.131(1903) | 2011-05-26 19:20:21.683 CDT | 17277 | | 0>LOG:
disconnection: session time: 0:00:00.008 user=usuarios database=rq
host=192.168.1.131 port=1903

Si revisamos el log se podría resumir así:

1. El equipo con IP 192.168.1.131 se conecta a la base de datos, el día 26
de Mayo de 2011, a las 7:20:14.908 pm, con el PID 17266 y se indica un port
(Remoto) 1898.

2. El equipo se desconecta, el día 26 de Mayo de 2011, a las 7:20:14.917 pm,
del mismo PID (17266) y port (1898).

3. Posteriormente el equipo con IP 192.168.1.131 se conecta a la base de
datos, el día 26 de Mayo de 2011, a las 7:20:14.918 pm, con el PID 17267 y
se indica un port (Remoto) 1899.

4. El equipo se desconecta, el día 26 de Mayo de 2011, a las 7:20:14.928 pm,
del PID (17267) y port (1899).

5. Entonces llegamos al "evento": el equipo con IP 192.168.1.131 se conecta
a la base de datos, el día 26 de Mayo de 2011, a las 7:20:19.856 pm, con el
PID 17268 y se indica un port (Remoto) 1901.

6. Entonces en la aplicación cuando intenta usar el "handle" que resulta de
la conexión del punto 5, el ODBC no permite realizar un select, o un insert,
o un update o un delete.

7. El equipo con IP 192.168.1.131 se conecta a la base de datos, el día 26
de Mayo de 2011, a las 7:20:21.545 pm, con el PID 17269 y se indica un port
(Remoto) 1902.

8. El equipo se desconecta, el día 26 de Mayo de 2011, a las 7:20:21.667 pm,
del PID (17269) y port (1902).

9. El equipo se desconecta, el día 26 de Mayo de 2011, a las 7:20:21.667 pm,
del PID (17268) y port (1901).

10. Posteriormente el usuario se conecta y se deconecta del PID 17277 y port
(1903).

En resumen:

a) Del punto 1 al 4 la aplicación se conecta, realiza la consulta o
actualización, y se desconecta normalmente de la base de datos.
b) Del punto 5 al punto 9 se muestra que:
1. No se pudo trabajar con la conexión del PID 17268 y port(1901).
2. Como lo dije anteriormente el usuario cierra la pantalla, la vuelve a
abrir y trabaja normalmente pero ya con el PID 17268 y port(1902).
3. Extrañamente se cierran juntas los PID 17268 y 17269, de los ports
1902 y 1901.
c) En el punto 10 se muestra simplemente una conexión y desconexión normal
(PID 17277 y port(1903)).

Una cosa muy extraña que he detectado, y que de hecho es el único patrón
identificable, es que todos estos eventos suceden cuando el port de la
conexión es el 1901.

Ya hemos revisado la red, el firewall (Pfsense), antivirus, servidores,
políticas, errores de ODBC, etc, etc, y no he podido dar con una pista para
saber que está pasando.

De antemano agradezco su ayuda y/o comentarios para encontrar una solución a
esto.

Saludos!

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2011-05-27 02:53:08 Re: Conexión se pierde.
Previous Message Lazaro Rubén García Martinez 2011-05-26 21:39:35 Error durante la recuperacion en linea con Pgpool!!!