Message-ID: <013b01c4c347$195212c0$0403a8c0@fejleszt4>
From: =?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= <surrano@mailbox.hu>
To: <pgsql-bugs@postgresql.org>
References: <012601c4c292$6804b810$0403a8c0@fejleszt4>
	<26896.1099590388@sss.pgh.pa.us>
	<011201c4c33b$7bd722c0$0403a8c0@fejleszt4>
Subject: Killed backend won't rollback transaction?
Date: Fri, 5 Nov 2004 15:52:39 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit

Dear Gurus,

Version: PostgreSQL 7.4.3 on Linux.

I have two transactions trying to insert the same value in a unique index
(pkey).
Tested and if I simpy try two plain sql backends, everything's ok. However,
mine is a silly scenario.

Obviously, the first one locks something (I assume the tuple) since the
other one goes waiting.

If I end this transaction (either by COMMIT or ROLLBACK), the other
transaction resumes (either by pkey violation error or successful insert).

BUT if I kill the first transaction (with standard (15 Terminate) signal),
the second one stucks in "waiting".

I know it's not recommended to "kill -9 the postmaster", but it's plain
"kill", and I couldn't circumvent it.
What happend is that I
* called a plpgsql function that inserted in this pkey, then
* called a C function that
* called system() that
* called php that inserted the same value via another connection, sentenced
to waiting.

The process hung, with no cancellation possible (the backend wrote "Cancel
request sent" but nothing happened -- system() ignores interrupts).

I fixed the lock, but I wondered if it's considered a bug.

TIA,
G.