> >>> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
