This has come up before, but I was reminded of it again after noticing
how confused psql gets if you use control-C to get out of a long
"\lo_import" operation. Usually the control-C hits while waiting for
the backend to respond to a lowrite() function call. As psql is
currently coded, it just longjmp's back to the main loop. Eventually
the function call response arrives, and it'll be taken as the response
to the *next* command psql issues to the backend! All sorts of fun
ensues, but it's particularly bad if the next command is also a function
call (eg, you try \lo_import again).
A narrow view of this is that cancelConn should be set non-NULL while
doing \lo operations, but I think the problem is bigger than that.
Allowing a signal handler to do siglongjmp at random times is basically
guaranteed to break any program. For instance, if it happens during a
malloc() or free() call you probably get corrupted malloc data
structures, leading to crash later.
I think we should try very hard to get rid of the longjmp in the signal
handler altogether. I notice it doesn't work anyway in the Windows
port, so this would improve portability as well as safety. The signal
handler should just set a flag that would be checked at safe points,
much as we do in the backend. (The bit about doing PQcancel can stay,
though, since that's carefully designed to be signal-safe.)
Does anyone see a real strong reason why we need a longjmp directly
from the signal handler? I had first thought that we couldn't preserve
the current behavior of clearing the input buffer when control-C is
typed in the midst of entering a line --- but according to the readline
manual, libreadline handles that for itself. I'm not seeing any other
killer reasons to have it.
regards, tom lane
