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