"Magnus Hagander" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
