> >>> In this case, SIGINT (query cancel) will not help, because
> >>> all locks held by the transaction will still be held.
> >>
> >> Wrong.
>
> > Really?
>
> [ experiments... ] My apologies --- you are correct about
> the present behavior. If a SIGINT arrives while waiting for
> client input, it's just dropped on the floor. The locks
> *will* be dropped if the SIGINT arrives during actual query
> processing.
>
> It strikes me that this is incorrect behavior, at least for
> the case where the client has a transaction block open. It'd
> be better to define the interrupt as "transaction cancel".
That sounds reasonable. That would certainly solve this part.
That leaves justo ne part of the issue - ability to "kill off" idle
backends. Since they do use up backend "slots" (of which there is a
limited number), I still think this wuold be good. Dunno if it might be
possible to use the same signal for that, under the following scheme:
if (query_running) cancel_query abort transaction
else if (idle in transaction) abort transaction
else if (idle not in transaction) graceful shutdown
or if that is too confusing? Fromt he "idle not in transaction", it
should be possibleo treat it the same way a "connection lost" would be,
no? (Instead of forcibly going down as SIGTERM does).
With that, I would definitly think limiting to SIGINT would be enough.
A question on using xids for identification instead of PIDs: is there a
xid assigned to a process thati s in the state "idle not in
transaction"? Otherwise, there still needs to be a way to send a signal
to those. I don't see why the PID is not a good idea (assuming
only-backends-restriction, but is even that necessary if you just send
SIGINT?)
//Magnus