[pgsql-es-ayuda] Matar un UPDATE

2016-12-23 Por tema Gustavo Vaccaro 

  
  
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

[pgsql-es-ayuda] Consulta select y commit síncrono

2016-12-23 Por tema Lazaro Garcia 
Buenas a todos en la lista. Les escribo porque en unas pruebas que estoy
realizando noto un comportamiento que quisiera me ayudaran a comprender.

 

Para las pruebas utilizo sysbench con un tiempo de 5 minutos enviando
consultas de solo lectura a un PostgreSQL 9.6.1 para comparar el número de
transacciones que se pueden ejecutar en este intervalo de tiempo con
diferentes niveles de concurrencia (usuarios conectados). Mi duda radica en
que cuando synchronous_commit esta desactivado el número de transacciones
aumenta y disminuye un poco cuando está activo.

 

Sé que cuando syncronous commit está activo, primero se escribe en el WAL
antes de retornar el commit para garantizar la integridad y persistencia de
los datos (siempre y cuando la consulta involucre un cambio en la BD), ahora
mi pregunta es la siguiente:

 

Cuando la consulta no modifica los datos, el commit tiene lugar del mismo
modo que cuando no está activo syncronous commit ya que no hay que copiar
nada a los WAL?

 

Saludos a todos y feliz fin de año.

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

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 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 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&a=search&h=REL9_3_STABLE&st=commit&s=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] Consulta select y commit síncrono

2016-12-23 Por tema Alvaro Herrera 
Lazaro Garcia escribió:

> Cuando la consulta no modifica los datos, el commit tiene lugar del mismo
> modo que cuando no está activo syncronous commit ya que no hay que copiar
> nada a los WAL?

Cuando la consulta no modifica datos, no se efectúa commit porque no es
necesario.  Por lo tanto es irrelevante si es síncrono o asíncrono.

-- 
Á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 

  
  
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&a=search&h=REL9_3_STABLE&st=commit&s=check_for_interrupts

[pgsql-es-ayuda]

2016-12-23 Por tema Ernesto Lozano 
Señores

Comunidad PostgreSQL


Atencion Todos Los Miembros


Presente

Atencion a Todo el Equipo Humano que Labora para en la Comunidad PostgreSQL


Reciban de nuestra parte un caluroso abrazo cargado de mucha alegría y
entusiasmo. Queremos que estas navidades puedan compartir con sus seres
queridos las mejores experiencias. Que Dios colme sus hogares de
bendiciones, salud, paz, amor, Esperanza y Fe en prosperidad.

Deseamos de todo corazón que este venidero 2017 comience de la mejor
manera, con pasos orientados al logro de los anhelos y proyectos futuros,
para que tengan éxito a nivel personal y organizacional, permitiéndoles
convertir sus sueños en realidades, y contando con nuestra disposición para
seguir colaborando para agregar valor a sus proyectos presentes y futuros.

También aprovechamos la oportunidad de darles las gracias por  apoyar e
Impulsar  crecimiento en conjunto de esta Importante Comunidad Tecnologica
Globalmente y en lo personal para cada uno de Nosotros asi como en lo,
profesional y empresarial, en torno a las soluciones que ofrecemos con esta
Excelente Herramienta  este Nuevo Año seguiremos apoyandonos para
mantenernos mas de cerca a través de la súper-autopista de la información .



​

Especialmente queremos darles las gracias a todos , quienes con su apoyo
nos permiten crecer juntos día a día y retribuir su confianza a través de
nuestro compromiso en lograr la excelencia en los servicios de las
soluciones de negocios.

Dios mediante, en el 2017 continuaremos trabajando con pasión y entusiasmo
para lograr el éxito  mutuo como aliados de Valor a nuestra Comunidad. Como
siempre todos estaremos a su disposición permanentemente y mas cerca con
nuestros servicios incondicionañes comunitarios que les ayudarán con el
proceso de Captación – Conversión – Fidelización – Escalación y
Reconvercion a un profesional mejor mejor .

Reciban un gran abrazo de parte de nuestro equipo de trabajo que
incansablemente trabaja para ustedes. FELIZ NAVIDAD, y VENTUROSO , PROSPERO
Y EXITOSO AÑO 2017  gracias nuevamente por pertenecer a la gran familia de
HIA TECHNOLOGY GROUP CORP Y  de sus Empresas Filiales.
*Estaremos de Vacaciones...*

Además, te informamos que estaremos de *Vacaciones Colectivas del
24/Dic/2016 al 06/Ene/2017 (ambas fechas inclusive). Incorporándonos
nuevamente el 9/Ene/2017.*


[image: Cita]

-- 
Atentamente
Ernesto Lozano
Director General
Hia Techonology Systems, C.A.
ISV EnterpriseDB
The Enterprise Postgres Company
www.hiatechnology.co.ve
0058 241 867.20.23

[pgsql-es-ayuda] RE: [pgsql-es-ayuda] Consulta select y commit síncrono

2016-12-23 Por tema Lazaro Garcia 
Muchas gracias por tu respuesta.

Saludos.

-Mensaje original-
De: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com] 
Enviado el: viernes, 23 de diciembre de 2016 12:13
Para: Lazaro Garcia
CC: 'PostgreSQL Lista Castellano'
Asunto: Re: [pgsql-es-ayuda] Consulta select y commit síncrono

Lazaro Garcia escribió:

> Cuando la consulta no modifica los datos, el commit tiene lugar del 
> mismo modo que cuando no está activo syncronous commit ya que no hay 
> que copiar nada a los WAL?

Cuando la consulta no modifica datos, no se efectúa commit porque no es
necesario.  Por lo tanto es irrelevante si es síncrono o asíncrono.

-- 
Á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