On 12/2/15 9:26 AM, Peter J. Holzer wrote:
As explained in backend/utils/misc/timeout.c, the timers are never cancelled: If a timeout is cancelled, postgres just sees that it has nothing to do and resumes whatever it is doing.
Hrm, if those timers are really just for auth purposes then perhaps they should be cancelled. But aside from that, there's certainly other things that can signal a backend (including fairly normal things, like DDL). Offhand I don't think functions run in a CRITICAL block (and I don't think it'd be a good idea for them to). So really, functions have to be handle being interrupted.
This is also what I'm seeing: 60 seconds after start, the process receives a SIGALRM. If the process is idle or in a "normal" SQL statement at the time, thats not a problem. But if it is in one of my stored procedures which is currently calling a ØMQ function which is waiting for some I/O (zmq_msg_recv(), most likely), that gets interrupted and returns an error which my code doesn't know how to handle (yet). So the error gets back to the user.
Yeah, it'd be nice to detect that this had happened. Or maybe it's worth it to ignore SIGALARM while a UDF is running. (We certainly wouldn't want to do a HOLD_INTERRUPTS() though...)
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
