php / php-src

The PHP Interpreter
https://www.php.net
Other
38k stars 7.73k forks source link

Connection problems with postgres pdo using php 8.3.10 and 8.2.22 #15637

Closed mathieu-pillar closed 4 weeks ago

mathieu-pillar commented 4 weeks ago

Description

The following code:

// Database connection details
$host = '<ip of common database>';
$dbname = 'postgres'; 
$user = 'postgres';
$pass = '<password>';

try {
    // Create a new PDO instance
    $dsn = "pgsql:host=$host;dbname=$dbname";
    $pdo = new PDO($dsn, $user, $pass);

    // Set error mode to exception
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

    // SQL query
    $sql = "SELECT * FROM topics LIMIT 20";

    // Execute the query
    $stmt = $pdo->query($sql);

    // Fetch all results
    $topics = $stmt->fetchAll(PDO::FETCH_ASSOC);

    // Display the results
    foreach ($topics as $topic) {
        echo "ID: " . $topic['id'] . " - Title: " . $topic['display_name'] . "\n";
    }

} catch (PDOException $e) {
    // Handle connection error
    echo "Connection failed: " . $e->getMessage();

    throw $e;
}

// Close the connection
$pdo = null;

Resulted in this output:

Connection failed: SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailablePHP Fatal error:  Uncaught PDOException: SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailable in /home/forge/test.php:12
Stack trace:
#0 /home/forge/test.php(12): PDO->__construct()
#1 {main}
  thrown in /home/forge/test.php on line 12

Fatal error: Uncaught PDOException: SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailable in /home/forge/test.php:12
Stack trace:
#0 /home/forge/test.php(12): PDO->__construct()
#1 {main}
  thrown in /home/forge/test.php on line 12

But I expected this output instead:

My data from the table to be printed to the console

More context and tests

I have been working on setting up a production environment at work. We already had a staging server in place. So I am mirroring my setup that I have in staging for my production. I am now facing a wall trying to connect to a remote database other eth1 (private ip) between two Digital Ocean droplets. It all seems to point to a php source error.

Here is a network diagram of my setup.

image

Flow C and D work fine regardless of php version installed. They use localhost as host. Using php pdo.

Flow A and B use eth1 (private ip) on digital ocean to communicate between droplets inside the same VPC using php pdo

Flow A works only using php 8.3.2 (which was installed a few months ago). I installed 8.2 today which resolved to 8.2.22 and I get the exception mentioned above.

Flow B does not work with either 8.3.10 or 8.2.22

Also, I can connect to the common database using psql from both staging and production droplets without issue.

PHP Version

8.3.10, 8.2.22

Operating System

Ubuntu 22.04, Ubuntu 24.04

jeffdafoe commented 4 weeks ago

Is it possible that your expected result and current result sections are reversed?

cmb69 commented 4 weeks ago

Did you try to connect with psql? If that works with the same connection parameters, there might be a bug in PHP; otherwise more likely there's an issue with your setup.

devnexen commented 4 weeks ago

Also, I can connect to the common database using psql from both staging and production droplets without issue.

I think the OP had mentioned he was successful with psql. What could be possible is the DSN part needs more settings.

mathieu-pillar commented 4 weeks ago

Is it possible that your expected result and current result sections are reversed?

Yes indeed, I will correct this

mathieu-pillar commented 4 weeks ago

Did you try to connect with psql? If that works with the same connection parameters, there might be a bug in PHP; otherwise more likely there's an issue with your setup.

Yes, I can do flows A to D using psql without any problems. Issue only comes up on specific versions of pdo php

devnexen commented 4 weeks ago

Did you try to connect with psql? If that works with the same connection parameters, there might be a bug in PHP; otherwise more likely there's an issue with your setup.

Yes, I can do flows A to D using psql without any problems. Issue only comes up on specific versions of pdo php

I had a couple of questions :

1/ The various php versions used are they official apt packages for 8.3.10/8.2.22 then 8.3.2 ? ppa repositories ? compiled from source ? 2/ Would the connection still fails if you re trying to connect to the db using the pgsql extension (ie pg_connect) ?

mathieu-pillar commented 4 weeks ago

Did you try to connect with psql? If that works with the same connection parameters, there might be a bug in PHP; otherwise more likely there's an issue with your setup.

Yes, I can do flows A to D using psql without any problems. Issue only comes up on specific versions of pdo php

I had a couple of questions :

1/ The various php versions used are they official apt packages for 8.3.10/8.2.22 then 8.3.2 ? ppa repositories ? compiled from source ? 2/ Would the connection still fails if you re trying to connect to the db using the pgsql extension (ie pg_connect) ?

  1. It is installed automatically by Laravel Forge. There is some general documentation, but nothing on the process itself. If I look in the /etc/apt directory and I look for php I can find this. I think those are ppa repository.
    forge@servername:/etc/apt$ grep php -R .
    ./sources.list.d/laravelphp-ubuntu-forge-noble.sources:URIs: https://ppa.launchpadcontent.net/laravelphp/forge/ubuntu/
    ./sources.list.d/ondrej-ubuntu-php-noble.sources:URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/
  2. I wil test this out. never used pg_connect before.
mathieu-pillar commented 4 weeks ago

Ok, it works with pg_connect

<?php                                                                                                                                                                                [5/14041]
// Database connection details                                                                                                                                                                
$host = '<ip of common database>';
$dbname = 'postgres'; 
$user = 'postgres';
$pass = '<password>';                                                                                                                       
$port = '5432';      // e.g., 5432 (default PostgreSQL port)

// Connection string
$conn_string = "host=$host dbname=$dbname user=$user password=$pass port=$port";

// Establish a connection
$conn = pg_connect($conn_string);

if (!$conn) {
    // Handle connection error
    echo "Connection failed: " . pg_last_error();
    exit;
}

// SQL query with schema
$sql = "SELECT * FROM openalex.topics";

// Execute the query
$result = pg_query($conn, $sql);

if (!$result) {
    // Handle query error
    echo "Query failed: " . pg_last_error();
    exit;
}

// Fetch and display the results
while ($row = pg_fetch_assoc($result)) {
    echo "ID: " . $row['id'] . " - Title: " . $row['title'] . "<br>";
}

// Free result and close the connection
pg_free_result($result);
pg_close($conn);
?>

I think it might be related to Swoole. I have seen this issue but have not though much about it because when I install php mysql, I never use Swoole. But I just figured out that Laravel Forge installs Swoole by default (which I was not aware of). I will turning it off/uninstalling see if it fixes the problems.

cmb69 commented 4 weeks ago

Also check whether the server listens on a non-standard port. And also check whether the PostgreSQL client libraries are the same.

mathieu-pillar commented 4 weeks ago

Confirmed! The culprit is swoole.

I ran

sudo phpdismod swoole

Not necessary for my test, but i'm paranoid, so I restarted php-fpm

sudo systemctl restart php8.3-fpm.service

And no more errors.

Should I close issue here and report my problem in the swoole repository?

devnexen commented 4 weeks ago

might depend on the swoole version I believe.

mathieu-pillar commented 4 weeks ago

might depend on the swoole version I believe.

Ok, they already got that under their radar. I will close this here.

Thanks so much to everyone that helped me out today. It was really appreciated! @devnexen @cmb69 @jeffdafoe

Have a nice all