Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-27 Por tema Alvaro Herrera 
Gustavo Vaccaro escribió:
> Jaime,
> 
> si yo tambien pienso que puede ser el debugger (pldebugger) en este caso.
> 
> Pero me paso una vez una base de datos que estaba en producción. No pude matar
> el proceso. Tuve que reiniciar el postgres.
> 
> Como ya te dije, pasa muy de vez en cuando y por eso es muy dificil de 
> tracear.
> Y mucho menos cuando los tiempos apremian y estan esperando que el sistema
> vuelva a funcionar.

Tengo entendido que el debugger de plpgsql opera conectando una segunda
sesión, la cual ejecuta funciones especiales para hacer que la
función-bajo-debugger continúe o se detenga.  Si matas la GUI mientras
las función-bajo-debugger está detenida, es obvio que se va a quedar
pegada hasta que la vuelvas a activar.  Eso lo deberías poder hacer
conectando otra sesión y ejecutando las funciones de debugger para
indicarle que continúe.  Desconozco la API exacta para decirle que a
plpgsql que se siga moviendo; la verdad es que como es un plugin
propietario de EDB, no me parece que esté súper documentado en forma
pública.  El código fuente está acá:
https://git.postgresql.org/gitweb/?p=pldebugger.git;a=summary

Me pregunto si esto efectúa un "sleep" cuando está detenido en un
breakpoint, y si es así, si sería posible usar un latch para que se
despierte en caso de recibir una señal.  Hmm.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-27 Por tema Gustavo Vaccaro 

  
  
Jaime,
si yo tambien pienso que puede ser el debugger (pldebugger) en
  este caso.
Pero me paso una vez una base de datos que estaba en producción.
  No pude matar el proceso. Tuve que reiniciar el postgres.
Como ya te dije, pasa muy de vez en cuando y por eso es muy
  dificil de tracear. 
  Y mucho menos cuando los tiempos apremian y estan esperando que el
  sistema vuelva a funcionar.

Pero con tiempo creo que lo voy encontrar.
Muchas gracias por tu ayuda.
Saludos


  
  
  
  
Gustavo J. Vaccaro
  http://www.gjv.com.ar
  

El 27/12/2016 a las 01:03 p.m., Jaime
  Casanova escribió:


  2016-12-27 7:24 GMT-05:00 Gustavo Vaccaro :

  

te agradezco el interés por el tema, pero el problema ya no existe porque
reinicie el postgres.

Es algo que me surge muy de vez en cuando y no lo puedo repetir para
realizar pruebas.
Cuando encuentre la forma de recrear el problema voy a profundizar sobre el
tema.


  
  
mi sospecha es que esto es causado por el debugger, supongo que
estamos hablando de pldebugger y chequea mientras el trigger se esta
ejecutando.

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-27 Por tema Jaime Casanova 
2016-12-27 7:24 GMT-05:00 Gustavo Vaccaro :
>
> te agradezco el interés por el tema, pero el problema ya no existe porque
> reinicie el postgres.
>
> Es algo que me surge muy de vez en cuando y no lo puedo repetir para
> realizar pruebas.
> Cuando encuentre la forma de recrear el problema voy a profundizar sobre el
> tema.
>

mi sospecha es que esto es causado por el debugger, supongo que
estamos hablando de pldebugger y chequea mientras el trigger se esta
ejecutando.


-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-27 Por tema Gustavo Vaccaro 

  
  
Jaime,
te agradezco el interés por el tema, pero el problema ya no
  existe porque reinicie el postgres.
Es algo que me surge muy de vez en cuando y no lo puedo repetir
  para realizar pruebas.
  Cuando encuentre la forma de recrear el problema voy a profundizar
  sobre el tema.

Saludos


  
  
  
  
Gustavo J. Vaccaro
  http://www.gjv.com.ar
  

El 27/12/2016 a las 01:12 a.m., Jaime
  Casanova escribió:


  2016-12-23 9:27 GMT-05:00 Gustavo Vaccaro :

  

Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el UPDATE esta vivo
con PID 11160.


  
  
podríamos ver el resultado completo del pg_stat_activity?

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-26 Por tema Jaime Casanova 
2016-12-23 9:27 GMT-05:00 Gustavo Vaccaro :
>
> Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el UPDATE esta vivo
> con PID 11160.
>

podríamos ver el resultado completo del pg_stat_activity?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Gustavo Vaccaro 

  
  
Alvaro,
en ningun momento tome tu pregunta como inutil o poco relevante.
Simplemente estaba buscando una respuesta a lo que podia ser un
  simple error de configuracion.

La opcion
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
  podría probarla en otro momento del año.
No creo haber preguntado nada fuera de lugar para recibir una
  respuesta como la tuya.
  Tus conocimientos en postgres (y los de la mayoría en la lista)
  son superiores por lejos a los mios pero no creo que por eso debas
  responder de esa manera.
  Si te fijas en la lista casi no hago preguntas. Generalmente acudo
  a las respuestas y a google.
Voy a tratar de ser mas moderado en el futuro, no preguntar lo
  obvio y seguir todos los pasos que vos me indiques antes de volver
  a preguntar.
Saludos y felices fiestas.


  
  
  
  
Gustavo J. Vaccaro
  http://www.gjv.com.ar
  

El 23/12/2016 a las 02:09 p.m., Alvaro
  Herrera escribió:


  Gustavo Vaccaro escribió:

  
La tabla tiene un trigger que se dispara con el update. Esta en plpgsql.

El trigger toca una tabla STOCK_ART.
Los FKs no se ven afectados porque solo se actualiza un campo de cantidad.
Cuando se anula el remito lo que hace es revertir el stock. Nada mas. No
inserta ni borra nada.

Lo raro es que me paso con esta tabla ahora, pero ya me habia pasado con otra
tabla que no toca ese trigger.
Ojo que no es algo frecuente. Creo que en el año me paso una o dos veces y
siempre cuando estoy haciendo pruebas.
Los triggers no tienen ningun bucle. Solo un UPDATE a otra tabla.

Pero independientemente de las tablas y los triggers, mi pregunta es porque no
puedo matar un proceso en mi postgres 9.3 en Win 7 64 bits.

¿Tendra algun bug la version? ¿me falta configurar algo?

  
  
Mi tiempo es demasiado escaso como para que estuviera haciendo preguntas
inútiles.  Gracias por contestarlas aunque no te parecieran relevantes.

La razón para hacer esas preguntas es que existía la posibilidad de que
tuvieras triggers en otros lenguajes, donde no se ejecute verificación
de interrupciones que mataría al proceso en caso de recibir una señal.
Se supone que plpgsql tiene verificaciones en todos los bucles, con lo
cual el UPDATE debería terminar pronto.  Si tuvieras por ejemplo un
trigger en plpython el cual invoca código python (que no verifica
interrupciones), podrías mandarle todas las señales que quisieras y no
tendría ningún efecto.

Pero por lo visto no es el caso.  Así que mi sospecha es que hay un bug
por el cual en alguna parte falta la verificación de interrupciones en
alguna parte de plpgsql.  Por eso te pedí el stack trace: serviría para
verificar dónde falta esa verificación.  Pero no respondiste esa parte,
así que no tenemos cómo investigar el problema.

Las FKs también son relevantes aunque no se hagan cambios, por razones
internas que me da pereza describir (o quizás simplemente no tengo
tiempo).

No dijiste qué versión de 9.3 estás usando.  En versiones tempranas hay
algunos bugs que fueron corregidos; algunos ejemplos
https://git.postgresql.org/gitweb/?p=postgresql.git=search=REL9_3_STABLE=commit=check_for_interrupts

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Alvaro Herrera 
Gustavo Vaccaro escribió:
> La tabla tiene un trigger que se dispara con el update. Esta en plpgsql.
> 
> El trigger toca una tabla STOCK_ART.
> Los FKs no se ven afectados porque solo se actualiza un campo de cantidad.
> Cuando se anula el remito lo que hace es revertir el stock. Nada mas. No
> inserta ni borra nada.
> 
> Lo raro es que me paso con esta tabla ahora, pero ya me habia pasado con otra
> tabla que no toca ese trigger.
> Ojo que no es algo frecuente. Creo que en el año me paso una o dos veces y
> siempre cuando estoy haciendo pruebas.
> Los triggers no tienen ningun bucle. Solo un UPDATE a otra tabla.
> 
> Pero independientemente de las tablas y los triggers, mi pregunta es porque no
> puedo matar un proceso en mi postgres 9.3 en Win 7 64 bits.
> 
> ¿Tendra algun bug la version? ¿me falta configurar algo?

Mi tiempo es demasiado escaso como para que estuviera haciendo preguntas
inútiles.  Gracias por contestarlas aunque no te parecieran relevantes.

La razón para hacer esas preguntas es que existía la posibilidad de que
tuvieras triggers en otros lenguajes, donde no se ejecute verificación
de interrupciones que mataría al proceso en caso de recibir una señal.
Se supone que plpgsql tiene verificaciones en todos los bucles, con lo
cual el UPDATE debería terminar pronto.  Si tuvieras por ejemplo un
trigger en plpython el cual invoca código python (que no verifica
interrupciones), podrías mandarle todas las señales que quisieras y no
tendría ningún efecto.

Pero por lo visto no es el caso.  Así que mi sospecha es que hay un bug
por el cual en alguna parte falta la verificación de interrupciones en
alguna parte de plpgsql.  Por eso te pedí el stack trace: serviría para
verificar dónde falta esa verificación.  Pero no respondiste esa parte,
así que no tenemos cómo investigar el problema.

Las FKs también son relevantes aunque no se hagan cambios, por razones
internas que me da pereza describir (o quizás simplemente no tengo
tiempo).

No dijiste qué versión de 9.3 estás usando.  En versiones tempranas hay
algunos bugs que fueron corregidos; algunos ejemplos
https://git.postgresql.org/gitweb/?p=postgresql.git=search=REL9_3_STABLE=commit=check_for_interrupts

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Gustavo Vaccaro 

  
  
La tabla tiene un trigger que se dispara con el update. Esta en
  plpgsql.

El trigger toca una tabla STOCK_ART.
  Los FKs no se ven afectados porque solo se actualiza un campo de
  cantidad.
  Cuando se anula el remito lo que hace es revertir el stock. Nada
  mas. No inserta ni borra nada. 

Lo raro es que me paso con esta tabla ahora, pero ya me habia
  pasado con otra tabla que no toca ese trigger.
  Ojo que no es algo frecuente. Creo que en el año me paso una o dos
  veces y siempre cuando estoy haciendo pruebas.
  Los triggers no tienen ningun bucle. Solo un UPDATE a otra tabla.
Pero independientemente de las tablas y los triggers, mi pregunta
  es porque no puedo matar un proceso en mi postgres 9.3 en Win 7 64
  bits.
¿Tendra algun bug la version? ¿me falta configurar algo?

Saludos


  
  
  
  
Gustavo J. Vaccaro
  http://www.gjv.com.ar
  

El 23/12/2016 a las 12:53 p.m., Alvaro
  Herrera escribió:


  Gustavo Vaccaro escribió:

  
Hola,

tengo un problema que me pasa muy de vez en cuando pero no tengo idea como
solucionarlo sin cerrar el postgres.

Recien desde un programa se ejecutó una sentencia: "UPDATE remitoegr SET
anulado = 'S' WHERE id_nroemp = 5 AND id_nroremito = 118"

Estaba corriendo el debug de PGADMIN sobre un trigger que se dispara con el
update en la tabla remitoegr y cerré sin darme cuenta la ventana que me abrio
el debug.

Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el UPDATE esta vivo
con PID 11160.

Ejecuto "SELECT pg_terminate_backend(11160)" y no pasa nada.

  
  
¿tiene triggers la tabla?  ¿en qué lenguaje están escritos?

¿tiene FKs?

Si ninguna de esas cosas explica el comportamiento, sería muy útil que
pudieras conectarle un debugger y tomar un "backtrace".
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Gustavo Vaccaro 

  
  
Ya lo hice y pasa lo mismo.

  
  
  
  
Gustavo J. Vaccaro
  http://www.gjv.com.ar
  

El 23/12/2016 a las 12:10 p.m., Lazaro
  Garcia escribió:


  
  
  
  
Podrías
intentar con pg_cancel_backend(pid)??
 
Saludos
a todos.
 

  
De:
pgsql-es-ayuda-ow...@postgresql.org
[mailto:pgsql-es-ayuda-ow...@postgresql.org] En
  nombre de Gustavo Vaccaro
Enviado el: viernes, 23 de diciembre de 2016 9:27
Para: pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] Matar un UPDATE
  

 
Hola,
tengo un problema que me pasa muy de vez en cuando pero no
  tengo idea como solucionarlo sin cerrar el postgres.
Recien desde un programa se ejecutó una sentencia: "UPDATE
  remitoegr SET anulado = 'S' WHERE id_nroemp = 5 AND
  id_nroremito = 118"
Estaba corriendo el debug de PGADMIN sobre un trigger que se
  dispara con el update en la tabla remitoegr y cerré sin darme
  cuenta la ventana que me abrio el debug.
Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el
  UPDATE esta vivo con PID 11160.
Ejecuto "SELECT pg_terminate_backend(11160)" y no pasa nada.
El usuario que utilizo es postgres y es superusuario. El
  usuario del UPDATE es admin y tambien superusuario.
Estoy corriendo postgresql 9.3 sobre win 7 64. Es mi entorno
  de desarrollo y pruebas.
¿Alguna idea como matar el UPDATE o cual es el problema?
Saludos
 

  -- 

Gustavo J. Vaccaro
http://www.gjv.com.ar

  
  Se certificó
que el correo no contiene virus.
Comprobada por AVG - www.avg.com
Versión: 2016.0.7924 / Base de datos de virus: 4739/13640 -
Fecha de la versión: 23/12/2016

Re: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Alvaro Herrera 
Gustavo Vaccaro escribió:
> Hola,
> 
> tengo un problema que me pasa muy de vez en cuando pero no tengo idea como
> solucionarlo sin cerrar el postgres.
> 
> Recien desde un programa se ejecutó una sentencia: "UPDATE remitoegr SET
> anulado = 'S' WHERE id_nroemp = 5 AND id_nroremito = 118"
> 
> Estaba corriendo el debug de PGADMIN sobre un trigger que se dispara con el
> update en la tabla remitoegr y cerré sin darme cuenta la ventana que me abrio
> el debug.
> 
> Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el UPDATE esta vivo
> con PID 11160.
> 
> Ejecuto "SELECT pg_terminate_backend(11160)" y no pasa nada.

¿tiene triggers la tabla?  ¿en qué lenguaje están escritos?

¿tiene FKs?

Si ninguna de esas cosas explica el comportamiento, sería muy útil que
pudieras conectarle un debugger y tomar un "backtrace".
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

RE: [pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Lazaro Garcia 
Podrías intentar con pg_cancel_backend(pid)??

 

Saludos a todos.

 

De: pgsql-es-ayuda-ow...@postgresql.org
[mailto:pgsql-es-ayuda-ow...@postgresql.org] En nombre de Gustavo Vaccaro
Enviado el: viernes, 23 de diciembre de 2016 9:27
Para: pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] Matar un UPDATE

 

Hola,

tengo un problema que me pasa muy de vez en cuando pero no tengo idea como
solucionarlo sin cerrar el postgres.

Recien desde un programa se ejecutó una sentencia: "UPDATE remitoegr SET
anulado = 'S' WHERE id_nroemp = 5 AND id_nroremito = 118"

Estaba corriendo el debug de PGADMIN sobre un trigger que se dispara con el
update en la tabla remitoegr y cerré sin darme cuenta la ventana que me
abrio el debug.

Cuando ejecuto "SELECT  * FROM pg_stat_activity" veo que el UPDATE esta vivo
con PID 11160.

Ejecuto "SELECT pg_terminate_backend(11160)" y no pasa nada.

El usuario que utilizo es postgres y es superusuario. El usuario del UPDATE
es admin y tambien superusuario.

Estoy corriendo postgresql 9.3 sobre win 7 64. Es mi entorno de desarrollo y
pruebas.

¿Alguna idea como matar el UPDATE o cual es el problema?

Saludos

 

-- 

Gustavo J. Vaccaro
  http://www.gjv.com.ar