Re: Function to kill backend - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Function to kill backend
Date
Msg-id 24431.1081262981@sss.pgh.pa.us
Whole thread Raw
In response to Re: Function to kill backend  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Function to kill backend
Next
From: Tom Lane
Date:
Subject: Re: Solaris initdb fails: shmmax tweak alternative?