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

Ok. That's a good point :-)


> (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.)

Sounds good to me.


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

Yeah, under that assumption, it certainly is enough.


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

I still say we need this. Is there some other good mechanism to do this
that you see? Since SIGTERM is not good... (I for one would definitly be
happy enough with being able to drop something that's in "idle without
transaction", since you can always use SIGINT to get it down to that
level)


//Magnus

Tue, 6 Apr 2004 17:00:16 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: Function to kill backend 
"Magnus Hagander" <mha@sollentuna.net> writes:
>> If we are going to allow session kill then of course we need 
>> PID for that.

> I still say we need this.

Well, that seems to be the consensus, so I won't stand in the way.

If you like the cancel-by-XID idea then I'd suggest providing two
functions: pg_cancel_query(XID) to send SIGINT and pg_kill_session(PID)
to send SIGTERM.  I'm not sure if the other two combinations (SIGINT by
PID and SIGTERM by XID) are worth providing.

			regards, tom lane

Tue, 06 Apr 2004 11:08:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function to kill backend 
Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> >> If we are going to allow session kill then of course we need 
> >> PID for that.
> 
> > I still say we need this.
> 
> Well, that seems to be the consensus, so I won't stand in the way.
> 
> If you like the cancel-by-XID idea then I'd suggest providing two
> functions: pg_cancel_query(XID) to send SIGINT and pg_kill_session(PID)
> to send SIGTERM.  I'm not sure if the other two combinations (SIGINT by
> PID and SIGTERM by XID) are worth providing.

Agreed.  Two functions, cancel by xid (skips cancel if xid changes
during command), and kill by pid for remote admin apps, is great.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 6 Apr 2004 11:15:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Function to kill backend