Bug #62571 [NoF->Csd]: Postgres PDO connections fail after SIGCHLD called

[willfitch]

Edit report at https://bugs.php.net/bug.php?id=62571&edit=1

 ID: 62571
 Updated by: willfi...@php.net
 Reported by:spiros_ioannou at yahoo dot gr
 Summary:Postgres PDO connections fail after SIGCHLD called
-Status: No Feedback
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.3.14
 Assigned To:willfitch
 Block user comment: N
 Private report: N



Previous Comments:

[2013-10-30 23:25:49] willfi...@php.net

Closing as no feedback has been provided since I asked for it in 2012.


[2012-12-18 21:23:52] willfi...@php.net

Can you provide a test script for your issue?


[2012-07-21 11:46:39] spiros_ioannou at yahoo dot gr

When using persistent connections, even if reopening a new connection *after* 
forking, the connection fails. The only way to have DB connections is to reopen 
them after forking, with PDO::ATTR_PERSISTENT => false


[2012-07-16 00:12:14] spiros_ioannou at yahoo dot gr

I revoke the statement of SIGCHLD, it happens even without the handler in some 
situations, the behaviour seems erratic. Perhaps the database connection is 
shared with the children, and when the child dies the db variable the 
connection is closed. 

I tried closing the DB connection first thing on the child but with no results, 
the error still appears when the child dies.


[2012-07-15 23:27:50] spiros_ioannou at yahoo dot gr

Description:

When using pcntl_fork to fork children, and *only* the parent uses the Postgres 
PDO database connection, the connection becomes unusable after the first child 
exits and the signal handler is called. If SIGCHLD signal handler is omitted 
PDO works normally for parent. Tested with and without persistent connections.
Possible relevant bugs: 48447, 45797

Actual result:
--
PHP Warning:  PDOStatement::execute(): SQLSTATE[HY000]: General error: 7 server 
closed the connection unexpectedly
This probably means the server terminated abnormally






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62571&edit=1

Req #35326 [Com]: Concurrency issue with recursive mkdir

[gustavo dot straube at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=35326&edit=1

 ID: 35326
 Comment by: gustavo dot straube at gmail dot com
 Reported by:bugs dot php dot net at chsc dot dk
 Summary:Concurrency issue with recursive mkdir
 Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

> We don't need a locking mechanism. If the creation of a directory fails, we 
> just need to check if it exists anyway [...]

In the application I experienced this bug, I do have a condition before the 
directory creation.

1. if (!is_dir($path))
2.   mkdir($path, 0755, true);

If I have two concurrent process ("A" and "B") running the code in this order 
(process - line):

A - 1
B - 1
B - 2
A - 2

When process "A" verified the directory existence, it really didn't exist.


Previous Comments:

[2013-10-30 08:49:24] bugs dot php dot net at chsc dot dk

> To create the right locking mechanism to avoid such issue to happen

We don't need a locking mechanism. If the creation of a directory fails, we 
just need to check if it exists anyway (i.e. it has been created by a 
concurrent thread). If it does, we can proceed to create the subdirectories.


[2013-10-01 04:52:05] paj...@php.net

Update the status.

And adding a small note about "why is it not a php bug", what is described here 
can happen anywhere outside php as well, be a shell script, ftp/ssh, etc.


[2013-10-01 04:21:25] paj...@php.net

Should have been:

... and will drastically affect performance without actually solving the 
problem


[2013-10-01 04:15:57] paj...@php.net

I am not sure it is actually a PHP problem. To create the right locking 
mechanism 
to avoid such issue to happen between (almost) simultaneous requests is the 
application developer job, not the core.

Adding such tests should be done in almost all file creation operations (and 
some 
other) and will drastically performance without actually solving the problem.


[2013-09-30 10:39:45] me at vlastv dot ru

Problem still exists in PHP 5.4.1.




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

https://bugs.php.net/bug.php?id=35326


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=35326&edit=1