Per http://www.mediawiki.org/wiki/Manual:Installation_requirements#Database_server MediaWiki requires PostgreSQL 8.1 or later.

etienne.massip wrote:

Well, you don't get me.

Whatever the Postgresql version is, as soon as I'm using PHP 5.2.6 windows setup package which contains binaries compiled with an old version of Postgresql, pg_version() does not do the job.

The PHP source has this:

#if HAVE_PQPARAMETERSTATUS
if (PQprotocolVersion(pgsql) >= 3) {

add_assoc_string(return_value, "server", (char*)PQparameterStatus(pgsql, "server_version"), 1);

}
#endif

Most likely the culprit is an old version of libpq which has a protocol version less than 3. It needs an informative error message advising the user to upgrade their client library; I don't think supporting old client libraries is a worthwhile goal.

Make that a server with protocol version less than 3, i.e. PostgreSQL 7.3 or earlier.

etienne.massip wrote:

I'm pretty sure libpq is not the cause, I use the one installed with Postgresql 8.24. And phpinfo() returns me a 8.2.3 library version (which is correct and matches pg_version()['client']) in the pgsql module extended information paragraph.

Do you or do you not have a copy of PostgreSQL 7.3 or earlier, locally or network-accessible? Because I was able to reproduce this by installing the 7.3 server. Appropriate error message added in r45624, intended for release in 1.14.

etienne.massip wrote:

I don't; 8.2 is the first and only version ever installed on this computer.

It seems to me that version comparison using numeric_version has been...numeric (comparing floats) until now; is it right to set this member to a literal string ?

etienne.massip wrote:

Okay, just forget my latest comment, I just don't recognize text color with my morning brain.

etienne.massip wrote:

Now I get '7.3 or earlier' string in Special:Page which is great, but wrong in my case.

etienne.massip wrote:

As I said before, there is a way to get server version before 7.4 : pg_parameter_status( $this->mConn, 'server_version' )

Etienne, that's an academic point. If any part of the chain is less than version 8, the version string will be the least of the problems.

etienne.massip wrote:

If you take the last comment alone, that is true.
But could you read the whole part of this ticket and try to understand that the bug is not in the way the DBMS version is rendered in but that this DBMS version is not the real one, only the version of the DBMS the client library has been compiled with.
The underlying DBMS version is 8.2, and MediaWiki find a '7.3 or earlier' (see comment #9). And as Alex stated in comment #1, this make a huge difference as mw does not support PostGreSQL 7.x. I had to alter the setup to force it.

daniel.ziegenberg wrote:

Well, in the actual Version (1.14.0) this Bug is still not fixed even though the source code has changed from the original version in posting #1. I had an setup of Windows Server 2003 with IIS 6.0 and PHP (description of the Setup can be found in the Mediawiki Wiki) and PostgreSQL 8.3.6 and it's for shure that there was nerver ever (neither on the server itself nor in the whole Intranet) an existing setup of any version of PostgreSQL. The only solution for me was to hack mediawiki\includes\db\DatabasePostgres.php Line 1073ff. an overwrite it with

function getServerVersion() {
$versionInfo = pg_version( $this->mConn );
$this->numeric_version = pg_parameter_status( $this->mConn, 'server_version' );
return $this->numeric_version;
}

So is there any hope for a future fix?

Daniel

<Sarcasm>I'm already looking forward to my next setup of mediawiki</Sarcasm>

only the version of the DBMS the client library has been compiled with.

This is the key point though: we can't be expected to run against a very, very old version of Postgres, even if "only" the client library. Version 7.4, which introduced PG protocol 3, came out in 2003. Version 7.3 of Postgres came out in *2002*. If you are working with something that was last updated against Postgres libraries from 2002 and is speaking PG protocol 2, there *will* be other problems. Far better to have it error out early with the version checking, than to limp along and hope that nothing else breaks. To put this in perspective, in 2002 MySQL version 4 had not even been released yet. Surely there is a precompiled version of PHP out there newer than that?

etienne.massip wrote:

No.

As a matter of fact, this may initially be dued to a PHP issue which prevents its src to be compiled PHP client with an "old" Postgresql CLI library (see http://bugs.php.net/bug.php?id=43214); a fix has been made in 5.2.5 but since then windows binaries delivered with windows PHP's package may be automatically compiled with an old Postresql version (this is pure speculation).

And pgsql extension in setups > 5.2.5 to 5.2.7 or 5.3.x, see http://bugs.php.net/bug.php?id=44905) are simply broken, so we had to use the 5.2.5 one.

But now that 5.2.7 is out, I'll throw an eye on it.

Do you have some specification of PG protocol v3 relative to server version determination ? I can't see anything in http://developer.postgresql.org/pgdocs/postgres/protocol.html.

karun.84 wrote:

From looking at this bug, I am not sure if this is actually an issue to do with Mediawiki.
Is there a standard or minimum version of Postgresql, that we require?
As perhaps we should have one, as surely it cannot be expected to create fixes to allow old versions such as from 2002 to work.

karun.84 wrote:

Hi, Unfortunately from the information on http://www.mediawiki.org/wiki/Manual:PostgreSQL, PostGreSQL 8.1 or later is needed, and hence a client library that supports PostGreSQL 8.1 or later, and protocol version 3 or later.

You will need to recompile php to support this version. Ive changed it to WONTFIX as it does not appear to be a bug with MediaWiki.

• Bug 18712 has been marked as a duplicate of this bug. ***

Reopening. Reproduced by three people, obviously the issue is not idiosyncratic. Needs a better error message, explaining exactly what is wrong. It would help if someone here could identify what the actual problem is.

Marking as release blocker for 1.15.

karun.84 wrote:

There are a number of WAMP(Windows Apache MySql/Postgresql PHP) Installers available for windows. Could you provide some information on how PHP is being installed? Is it through one of these installers?

That way it can be determined if it is the installer which is the problem.

daniel.ziegenberg wrote:

I did it all seperatly. First installing Apache, than PostgreSQL, than PHP (during installation I've chosen the PostgreSQL extension that come with that installer).
For PHP I used the php-5.2.9-1-win32-installer.msi from the official site. For PostgreSQL I used the newest available PostgreSQL 8.3 windows installer from the official site and for Apache I used the newes available Apache2.2 for Windows from original site.

Hope this helps.

karun.84 wrote:

Is it possible for you to send a copy of the output from the phpinfo() command, and add it as an attachment to the bug? Then I will be able to try to reproduce it.

karun.84 wrote:

Hello,
I am not sure this is a Mediawiki specific bug. I have found the following bug on the PHP website http://bugs.php.net/bug.php?id=48181 in where the reporter has a similiar problem with the latest version of php on windows.

So far there has been no update on the PHP website, in relation to this bug. So I guess maybe we should wait for an update on the PHP bug, before looking at if it is a bug with mediawiki?

It's a MediaWiki issue, we need to fix the error message in MediaWiki to explain what the problem is and how to work around it. It might even be possible to make MediaWiki work correctly with the older protocol version.

As for the PHP bug: they don't just fix themselves. It's in the PHP bug tracker in the same form that it's here: vague and unisolated. MediaWiki is a major PHP user and we often cooperate with the PHP devs to fix bugs like these.

In general, it's our policy to keep upstream bugs open until upstream is properly fixed. It helps users find the bug report, and gives people a place to comment when the upstream bug tracker is less accessible.

karun.84 wrote:

I have added the keyword upstream.
The upstream bug is here http://bugs.php.net/bug.php?id=48181

karun.84 wrote:

*** Bug 18742 has been marked as a duplicate of this bug. ***

karun.84 wrote:

tsnowman proposes in the forum page (http://www.mwusers.com/forums/showthread.php?t=10799) referred to in Bug 18742 proposes that the client and server versions is checked.
This approach appears to resolve the issue on Windows. I am unsure whether that is the best approach to correct the problem, as we may have a 8.1 client, and a 7.0 server.
/**

• @return string Version information from the database

	 */

function getServerVersion() {

		$versionInfo = pg_version( $this->mConn );
		if ( isset( $versionInfo['server'] ) ) {
			$this->numeric_version = $versionInfo['server'];
		} else {
			// There's no way to identify the precise version before 7.4, but 
			// it doesn't matter anyway since we're just going to give an error.
			$this->numeric_version = '7.3 or earlier';
		}
		return $this->numeric_version;

}

With regards to protocol used, this may be not as much of an issue, compared to whether the database and MediaWiki uses any PostGreSQL features that are only available in a specific version or later. From http://au.php.net/manual/en/pgsql.requirements.php it appears that specific functions require 8.0 or later. So if we are not using any functions that require 8.0 or late, it may be possible to just not check the postgresql version.

(In reply to comment #28)

tsnowman proposes in the forum page
(http://www.mwusers.com/forums/showthread.php?t=10799) referred to in Bug 18742
proposes that the client and server versions is checked.
This approach appears to resolve the issue on Windows.

It's completely wrong and broken. At least Etienne's suggestion in the initial report kind of made sense.

We already have the reproduction procedure in comment #22, all that needs to be done on this bug is for someone to reproduce it and isolate it in the relevant source code. We don't need guesswork.

karun.84 wrote:

(In reply to comment #29)

It's completely wrong and broken. At least Etienne's suggestion in the initial
report kind of made sense.

We already have the reproduction procedure in comment #22, all that needs to be
done on this bug is for someone to reproduce it and isolate it in the relevant
source code. We don't need guesswork.

I have reproduced the bug on Windows using the instructions in comment #22. It does not apply to the MediaWiki application and I have tried another application that has the same problem.
It works fine in my initial tests, if I disable version checking for PostGreSQL, but this could cause problems should someone try to install it on PostGreSQL 7.3 on other platforms than windows.

karun.84 wrote:

(In reply to comment #30)

(In reply to comment #29)

I have reproduced the bug on Windows using the instructions in comment #22. It
does not apply to the MediaWiki application and I have tried another
application that has the same problem.

My previous comment should have said it does not only apply to the MediaWiki application. The component which causes the problem is that the incorrect version number or no version number is returned by using the pg_versioninfo command

daniel.ziegenberg wrote:

I've added the requested phpinfo() output as an attachment. As the server is a our companies server I was told to override some parts.

daniel.ziegenberg wrote:

requested phpinfo output from comments #c23

Attached:

john.doyle wrote:

Hi All

I reported the php bug noted above. My issue is that PHP misreports the version of Postgresql that I have installed. I'm running Mediawiki 1.14.0 and I can't create new pages and searching doesn't work which I believe is related. I've got the latest versions of PHP (5.2.9) and Postgresql (8.3.7) installed. In DatabasePostgres.php in Mediawiki 1.14.0 the pg_version('server_version') function is used to obtain the version of PostgreSQL. The code:

<?php

$dbconn = pg_connect("my db connection")
   or die("Could not connect");
   
$v = pg_version($dbconn);

print_r($v);

?>

produces the array:
Array
(

[client] => 8.3.1

)

for PostgreSQL 8.3.7 thus I reported a bug to PHP. Mediawiki 1.13.2 doesn't have this problem as the getServerVersion() function uses the line:
$version = pg_fetch_result($this->doQuery("SELECT version()"),0,0);
to get the server version. I'm not sure why it was changed but could the change be reverted as Mediawiki 1.14.0 currently doesn't work with PostgreSQL because of it? Also I believe if PHP did fix the problem of pg_version reporting the wrong version of Postgresql then Mediawiki would still be broken as I think PHP would return the server version with the identifier 'server' and not 'server_version'.

john.doyle wrote:

This bug in redhat's bugzilla seems to be the same problem I'm having: https://bugzilla.redhat.com/show_bug.cgi?id=492825

karun.84 wrote:

(In reply to comment #34)

Also I believe if PHP did fix the problem of pg_version reporting the
wrong version of Postgresql then Mediawiki would still be broken as I think PHP
would return the server version with the identifier 'server' and not
'server_version'.

On linux I get the following

Array ( [client] => 8.3.7 [protocol] => 3 [server] => 8.3.7 ).

The Php documentation for pg_version http://au2.php.net/function.pg_version or perhaps the implementation in PHP appears to be inconsistent. As the documentation refers to server_version.

When you run the php script you posted do you get server_version or server in the array? If possible could you post the output of the array.

john.doyle wrote:

Nope I don't get any server or protocol in the array. I'm running this on Windows server 2003 as we're not allowed to use Linux here :-(

I finally installed Windows and reproduced this locally. It was easily isolated and Pierre-Alain Joye offered to commit my patches (despite my rudeness on IRC):

http://cvs.php.net/viewvc.cgi/php-src/ext/pgsql/config.w32?view=log

Search for HAVE_PQPROTOCOLVERSION. With a bit of luck they should be in the 5.2.10 and 5.3.0 releases.

It turns out that the bug is mostly limited to pg_version(). HAVE_PQPROTOCOLVERSION has never been defined for Windows builds, despite them having required PG 8.1 for some time. We can check the server version with Etienne's method, check the client version for sanity, and then continue with the installation.

Analysis of the source code suggests two minor related bugs:

• The ROLLBACK on request shutdown will be done unconditionally, instead of testing for an open transaction
• Persistent connections won't have RESET ALL run on them each time they are reused.

Neither affects us, as far as I can tell.

Proposed fix committed in r50473 and backported for release in MediaWiki 1.15. Please test it to make sure that your server version is detected correctly by the installer. Reopen this bug if the issue persists. The fix is to replace getServerVersion() in DatabasePostgres.php with this:

function getServerVersion() {

$versionInfo = pg_version( $this->mConn );
if ( version_compare( $versionInfo['client'], '7.4.0', 'lt' ) ) {
   // Old client, abort install
   $this->numeric_version = '7.3 or earlier';
} elseif ( isset( $versionInfo['server'] ) ) {
   // Normal client
   $this->numeric_version = $versionInfo['server'];
} else {
   // Bug 16937: broken pgsql extension from PHP<5.3
   $this->numeric_version = pg_parameter_status( $this->mConn, 'server_version' );
}
return $this->numeric_version;

}

etienne.massip wrote:

I searched this for a long time !

Thus, this was finally the meaning of the PHP manual quote "Protocol and server versions are only available if PHP was compiled with PostgreSQL 7.4 or later. " ! How mysterious !

Awesome job, guys, thanks a lot !

• Bug 19479 has been marked as a duplicate of this bug. ***

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.