php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #27824 pg_pconnect failing to create multiple connections per script
Submitted: 2004-04-01 08:51 UTC Modified: 2004-09-17 15:37 UTC
Votes:1
Avg. Score:2.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: gwood at ewebengine dot com Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.3.4 OS: FreeBSD 5.1-RELEASE-p10
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gwood at ewebengine dot com
New email:
PHP Version: OS:

 

 [2004-04-01 08:51 UTC] gwood at ewebengine dot com
Description:
------------
According to the documentation:

"An important summary. Persistent connections were designed to have one-to-one mapping to regular connections. That means that you should always be able to replace persistent connections with non-persistent connections, and it won't change the way your script behaves. It may (and probably will) change the efficiency of the script, but not its behavior!"

This does not appear to be the case with pg_pconnect. Specifically, creating two database connections using pg_pconnect with the same connection parameters, results in only a single database connection. This means that instead of being able to execute queries in parallel, all queries are executed sequentially.

This happens with both the CLI interface and mod_php.

Reproduce code:
---------------
$conn1 = pg_pconnect($connect_string);
$conn2 = pg_pconnect($connect_string);
pg_query($conn1, 'BEGIN');
pg_query($conn2, 'BEGIN');
pg_query($conn1, 'INSERT INTO test (int1) VALUES (1)');
pg_query($conn2, 'INSERT INTO test (int1) VALUES (2)');
pg_query($conn1, 'ROLLBACK');
pg_query($conn2, 'COMMIT');

Expected result:
----------------
This should result in the second insert to the database being committed, while the first insert is rolled back. This is what happens when pg_connect() is substituted for pg_pconnect.

Actual result:
--------------
Both inserts are rolled back.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-04-01 08:53 UTC] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When creating a persistent connection PHP uses the provided 
authentication information to determine is such connection 
is already avaliable. This is why when using pg_pconnect 
with the same data in one script would result in a single 
connection. 
 [2004-04-01 09:06 UTC] gwood at ewebengine dot com
If this isn't considered a bug, then the documentation is incorrect. The documentation states that persistant connections can be swapped out for non-persistant connections with no problem. This IS NOT TRUE for the example I presented.

If this is expected behaviour this caveat needs to be added to the warnings on the persistant connection page.
 [2004-04-01 09:23 UTC] derick@php.net
Non-persistent connections behave exactly the same as persistent ones for this too. If not, *that*'s a bug. Can you please verify that?
 [2004-04-01 09:52 UTC] gwood at ewebengine dot com
You are exactly correct, I apologize: I was incorrect about my expectations of pg_connect(). I reread the documentation with regards to this and sure enough that is the expected behavior.

In my testing I had mixed pg_pconnect() and pg_connect() which resulted in different results, hence my confusion.

I guess I'll have to fool PHP into thinking that they're two separate connections by creating a junk user or an alias for the host name. Ugh.
 [2004-04-01 09:56 UTC] derick@php.net
Making this a feature request, as the MySQL extension actually has a parameter to force a new connection.
 [2004-04-01 11:51 UTC] derick@php.net
It seems that it already exist, but it's not documented or no longer working correctly anymore.

It *seems* that you can can pass it like this:

pg_connect("conectionstring", PGSQL_CONNECT_FORCE_NEW);

also, the order of parameters documented in the manaul for the old *deprecated* way for connecting to PGSQL is wrong:
pg_connect("host", "port", "options", "tty", "dbname")

from what I read from the source it should be:

pg_connect(string connect_string [, int options ])
or
pg_connect(string host, string port, string db_name )
or
pg_connect(string host, string port, int options, string db_name)
or
pg_connect(string host, string port, int options, string db_name, string tty)


 [2004-04-01 11:51 UTC] derick@php.net
Oops, last one should be:
pg_connect(string host, string port, int options, string tty, string db_name)
 [2004-09-17 15:37 UTC] vrana@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"... no new connection will be established unless you pass PGSQL_CONNECT_FORCE_NEW as connect_type ..."
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Thu Sep 04 04:00:02 2025 UTC