BUG #3031: PHP (and others?) cannot close a connection when "in" a COPY-statement - Mailing list pgsql-bugs

From Arjen van der Meijden
Subject BUG #3031: PHP (and others?) cannot close a connection when "in" a COPY-statement
Date
Msg-id 200702191852.l1JIqNa2028060@wwwmaster.postgresql.org
Whole thread Raw
Responses Re: BUG #3031: PHP (and others?) cannot close a connection when "in" a COPY-statement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
The following bug has been logged online:

Bug reference:      3031
Logged by:          Arjen van der Meijden
Email address:      acmmailing@tweakers.net
PostgreSQL version: 8.2.1
Operating system:   Debian Linux (etch, 2.6.17 kernel)
Description:        PHP (and others?) cannot close a connection when "in" a
COPY-statement
Details:

We noticed that when issueing a 'die'-statement in php, compiled against
both 8.1 or 8.2 will not really die when just before the die-statement a
COPY-statement to postgresql was started. In stead it gets in some (busy
wait?) loop, consuming 100% cpu.

Here is some example code that triggers the behaviour:
<?
echo "Starting\n";
$conn = pg_connect('');
pg_query($conn, "CREATE TEMPORARY TABLE test (test integer);");
pg_query($conn, "COPY test FROM STDIN");
die("And now it hangs in with 100% cpu\n");
?>

Of course you'd expect a prompt to return, rather than the process consuming
all cpu and never returning.

I'm not sure whether this is a php-issue or a postgresql-client-api one, but
when connecting gdb to that process and doing a 'bt' it displays:
#0  0xa7c36d9f in free () from /lib/tls/libc.so.6
#1  0xa7c38c4f in malloc () from /lib/tls/libc.so.6
#2  0xa7f58bdb in PQmakeEmptyPGresult () from /usr/lib/libpq.so.5
#3  0xa7f59941 in PQgetResult () from /usr/lib/libpq.so.5
#4  0x08086fd0 in _close_pgsql_link (rsrc=0x81e42bc) at
/usr/src/php-4.4.2/ext/pgsql/pgsql.c:276
#5  0x08139fb2 in list_entry_destructor (ptr=0x81e42bc) at
/usr/src/php-4.4.2/Zend/zend_list.c:177
#6  0x08137977 in zend_hash_apply_deleter (ht=0x81a49e0, p=0x81e4284)
    at /usr/src/php-4.4.2/Zend/zend_hash.c:611
#7  0x08137b97 in zend_hash_graceful_reverse_destroy (ht=0x81a49e0)
    at /usr/src/php-4.4.2/Zend/zend_hash.c:677
#8  0x0812b9ed in shutdown_executor () at
/usr/src/php-4.4.2/Zend/zend_execute_API.c:211
#9  0x08133801 in zend_deactivate () at /usr/src/php-4.4.2/Zend/zend.c:689
#10 0x08107862 in php_request_shutdown (dummy=0x0) at
/usr/src/php-4.4.2/main/main.c:999
#11 0x0814ee56 in main (argc=2, argv=0xaf992f54) at
/usr/src/php-4.4.2/sapi/cli/php_cli.c:881

We can reproduce this on x86-boxes with recent php4 and the latest
php5(-cvs). I have not tested other sapi's than the cli-php versions but I
also tested it on a (amd64) gentoo box.

If it is a php-bug, perhaps it'd be usefull if one of you could comment
here: http://bugs.php.net/bug.php?id=40544

Best regards,

Arjen van der Meijden

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3015: libpq: PQftype() on a lo type result column returns Oid of type oid instead of Oid of type lo.
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #2973: Compile Error with MIPSpro compiler