
> > In this case, SIGINT (query cancel) will not help, because 
> all locks 
> > held by the transaction will still be held.
> 
> Wrong.

Really? 
Please point out where I am wrong in this:

SESSION A:		BEGIN TRANSACTION
SESSION A:		LOCK TABLE foo IN ACCESS EXCLUSIVE MODE
SESSION B:		SELECT * FROM foo      <-- blocks (expected)!
not-in-session:	KILL -INT <pid_of_session_A>
 (at this point, <pid_of_session_A> is listed as "idle in transaction")
SESSION B:        <-- still blcoks....
SESSION A: 		ROLLBACK
SESSION B:		<-- now completes

If I kill it with TERM instead of INT, SESSION B is released at that
point.

Am I missing something very obvious here?


This is on:
 PostgreSQL 7.4.2 on i686-pc-linux-gnu, compiled by GCC 2.95.3


//Magnus

Mon, 5 Apr 2004 11:05:53 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: Function to kill backend 
"Magnus Hagander" <mha@sollentuna.net> writes:
>>> 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".

			regards, tom lane

Mon, 05 Apr 2004 10:05:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function to kill backend 