Dear Tom,
----- Original Message -----
From: "Tom Lane" <[EMAIL PROTECTED]>
Sent: Friday, November 05, 2004 5:02 PM
> SIGTERM on individual backends is not recommended or supported.
That explains this. Keeping this policy in mind, I wouldn't qualify this as
a bug after all.
> FWIW, though, I could not duplicate this bug report. Are you sure you
> know what the second one was really waiting on?
Yeah I'm quite sure. See sample below. Ask for a working example if you
wish.
The main concept is that a system() call from a C function causes another
connection to be opened, and the original connection, after locking the
tuple, waits for the other connection (that is started implicitly by the C
function) that in turn waits for the locked tuple to be unlocked. Thus, the
transactions are "nested" even though they are on a different connection.
G.
%----------------------- cut here -----------------------%
-- table:
CREATE TABLE test_id (
id serial NOT NULL PRIMARY KEY,
retval varchar
);
-- there is a "before insert" trigger that allows retval of existing key
-- to be updated instead of inserted if retval is null (see PHP script
below)
-- plpgsql function:
CREATE PROCEDURE test_pl (int) RETURNS varchar AS '
declare
rv varchar;
begin
-- this can be delayed till the PHP call, but keeping here
-- helps reproduce the problem.
INSERT INTO test_id (id) VALUES ($1);
rv := test_c ($1);
rv := retval FROM test_id WHERE id = $1;
return rv;
end;
-- C function:
text *test_c (int)
{
...
system ("php -q test.php");
...
}
-- PHP script "test.php":
<?
...
// this gets converted to UPDATE but keeping as is
// helps reproduce the problem.
pg_exec($conn,
"INSERT INTO test_id (id, retval) VALUES (123, 3*123)");
...
?>
\end
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
