> >>> 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

Tue, 6 Apr 2004 16:41:38 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: Function to kill backend 
"Magnus Hagander" <mha@sollentuna.net> writes:
> 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?

Too hazardous.  Say you meant to kill a slow query, only it finishes
just before you press RETURN.  The above definition silently promotes
your query cancel into a session kill, which is not what you intended.

(Silently promoting query cancel to transaction cancel seems okay to me,
since a successful query cancel aborts the xact anyway.  However this
might need closer thought to consider what will happen with nested
xacts.)

> 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"?

No, and I assert you do not need one if the facility is limited to query
or transaction cancel; more, an XID-based identification would be less
prone to race conditions of the kind just mentioned (you couldn't
mistakenly zap the transaction after the one you meant to).

If we are going to allow session kill then of course we need PID for
that.

			regards, tom lane

Tue, 06 Apr 2004 10:49:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function to kill backend 