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

[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