ID: 40544
Updated by: [EMAIL PROTECTED]
Reported By: kees at tweakers dot net
Status: Assigned
Bug Type: PostgreSQL related
Operating System: Linux (Debian)
PHP Version: 5.2.1
Assigned To: yohgaki
New Comment:
>'Rollback on shutdown' is like 'Don't flush buffer before closing
file'.
I disagree, you need to commit everything explicitly.
If you didn't commit the transaction, it should be rolled back.
Previous Comments:
------------------------------------------------------------------------
[2007-04-05 01:28:11] yohgaki at ohgaki dot net
> And that's something I would call expected, because "rollback on
> shutdown" is much safer than "commit on shutdown".
As I wrote, under normal condition, current code(commit on shutdown)
does make more sense than rollback on shutdown because PostgreSQL
supports async query.
'Rollback on shutdown' is like 'Don't flush buffer before closing
file'. It does not acceptable for most people. (And more efficient if it
finish pending query at shutdown, too. If you are curious, take some
simple benchmarks)
However, under shared environment, it is not acceptable to consume all
connection by COPY FROM SDTIN. It is better to have a way to avoid such
action.
There are 2 options:
1) Leave it alone (and make DoS possible under shared environment)
2) Give administrators a option that cancel current and pending async
query.
I prefer first option. I'll ask PostgreSQL developer if it's possible
to have GRANT option for COPY in the future.
------------------------------------------------------------------------
[2007-03-09 10:11:12] [EMAIL PROTECTED]
>By calling PQcanel() before clean up resource, all async query which
>is not finished yet will be discarded instead of finishing its query.
And that's something I would call expected, because "rollback on
shutdown" is much safer than "commit on shutdown".
>I'll add new ini option that enables PQcancel() in
>list_entry_destructor. Any comments?
More INI options? No, thanks.
------------------------------------------------------------------------
[2007-03-08 04:24:24] yohgaki at ohgaki dot net
I didn't look the backtrace carefully. It stops when PQclear() is
called on the backtrace, while my PHP 5.2 stopeed at PQgetReuslt().
(Both of them are called when request is shutting down)
For at least PHP 5.2, it would be solved by calling PQcanel() when
cleaning up resource, but with compatibility issue. By calling PQcanel()
before clean up resource, all async query which is not finished yet will
be discarded instead of finishing its query.
I'll add new ini option that enables PQcancel() in
list_entry_destructor. Any comments?
------------------------------------------------------------------------
[2007-03-07 22:09:55] yohgaki at ohgaki dot net
Since COPY is not a actual SQL statement, PostgreSQL waits forever
until COPY ends because the input is STDIN. (SQL Statements like SELECT,
UPDATE, DELETE, INSERT will be aborted if there is deadlock)
Since PQfinish() (Used while shutting down pgsql connections) does not
have option to wait certain amount of time to force closing connection,
I'm not sure if it is feasible shutting down w/o waiting to finish COPY,
etc. It's possible to force close connection manually using internal
PGconn strucutre's connection parameter, but there would be portability
issues if it use PGconn internal parameters.
I'll see if there is I can do about this in feasible manner.
------------------------------------------------------------------------
[2007-02-19 15:52:58] kees at tweakers dot net
tested with the snapshot:
[EMAIL PROTECTED]:/usr/src/php5.2-200702191330$ sapi/cli/php test.3.php
Starting
And now he hangs in a busy wait
[ctrl-c]
[EMAIL PROTECTED]:/usr/src/php5.2-200702191330$ sapi/cli/php -v
PHP 5.2.2-dev (cli) (built: Feb 19 2007 16:49:22)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
ldd sapi/cli/php
libpq.so.5 => /usr/lib/libpq.so.5 (0xa7f3c000)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40544
--
Edit this bug report at http://bugs.php.net/?id=40544&edit=1
