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