Last modified: 2013-03-08 13:07:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16937 - PostgreSQL wrong protocol version
PostgreSQL wrong protocol version
Status: CLOSED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
unspecified
PC Windows XP
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: upstream
: 18712 18742 (view as bug list)
Depends on:
Blocks: postgres 18629
  Show dependency treegraph
 
Reported: 2009-01-08 09:46 UTC by Etienne Massip
Modified: 2013-03-08 13:07 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
requested phpinfo output from comments #c23 (47.25 KB, text/html)
2009-05-11 06:53 UTC, Daniel Ziegenberg
Details

Description Etienne Massip 2009-01-08 09:46:57 UTC
Firstly, I'm using PHP 5.2.6 for Windows (with php_pgsql.dll 5.2.5 because 5.2.6 is broken), installed from prepared setup.

Secondly, there is the getServerVersion() method from class PostgresField in MediaWiki's API (in file includes\db\DatabasePostgres.php) :

/**
 * @return string Version information from the database
 */
function getServerVersion() {
  $versionInfo = pg_version( $this->mConn );
  $this->numeric_version = $versionInfo['server'];
  return $this->numeric_version;
}

Thirdly, PHP manual page of pg_version(), available at http://php.net/function.pg_version, states that :

"Protocol and server versions are only available if PHP was compiled with PostgreSQL 7.4 or later. "

As a result, I get this line in Apache's error log :

PHP Notice:  Undefined index:  server in MediaWiki phase3\\includes\\db\\DatabasePostgres.php on line 1058

and a blank field in Special:Version Postgresql version. This also prevented me from running initial configuration setup where a minimal version comparison is done; so I fixed by replacing the "$this->numeric_version = $versionInfo['server'];" part with "$this->numeric_version = pg_parameter_status( $this->mConn, 'server_version' );" which works whatever dbms version the library was compiled with.
Comment 1 Alexandre Emsenhuber [IAlex] 2009-01-08 10:00:27 UTC
Per http://www.mediawiki.org/wiki/Manual:Installation_requirements#Database_server MediaWiki requires PostgreSQL 8.1 or later.
Comment 2 Etienne Massip 2009-01-08 10:33:32 UTC
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.
Comment 3 Tim Starling 2009-01-09 05:02:27 UTC
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. 
Comment 4 Tim Starling 2009-01-09 08:32:33 UTC
Make that a server with protocol version less than 3, i.e. PostgreSQL 7.3 or earlier. 
Comment 5 Etienne Massip 2009-01-09 10:22:04 UTC
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.
Comment 6 Tim Starling 2009-01-10 00:54:40 UTC
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.
Comment 7 Etienne Massip 2009-01-12 07:44:22 UTC
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 ?
Comment 8 Etienne Massip 2009-01-12 10:29:33 UTC
Okay, just forget my latest comment, I just don't recognize text color with my morning brain.
Comment 9 Etienne Massip 2009-01-12 10:42:23 UTC
Now I get '7.3 or earlier' string in Special:Page which is great, but wrong in my case.
Comment 10 Etienne Massip 2009-01-12 14:25:58 UTC
As I said before, there is a way to get server version before 7.4 : pg_parameter_status( $this->mConn, 'server_version' )
Comment 11 Greg Sabino Mullane 2009-03-12 15:34:31 UTC
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.
Comment 12 Etienne Massip 2009-03-13 13:01:38 UTC
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.
Comment 13 Daniel Ziegenberg 2009-03-16 13:54:28 UTC
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>
Comment 14 Greg Sabino Mullane 2009-03-23 13:21:19 UTC
> 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?
Comment 15 Etienne Massip 2009-03-24 09:12:22 UTC
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.

Comment 16 Karun 2009-05-04 22:19:23 UTC
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.
Comment 17 Karun 2009-05-05 06:59:16 UTC
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.
Comment 18 Tim Starling 2009-05-08 07:59:55 UTC
*** Bug 18712 has been marked as a duplicate of this bug. ***
Comment 19 Tim Starling 2009-05-08 08:03:35 UTC
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. 
Comment 20 Tim Starling 2009-05-08 08:05:56 UTC
Marking as release blocker for 1.15. 
Comment 21 Karun 2009-05-08 09:24:40 UTC
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.
Comment 22 Daniel Ziegenberg 2009-05-08 11:52:20 UTC
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.
Comment 23 Karun 2009-05-08 12:00:23 UTC
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.
Comment 24 Karun 2009-05-09 00:18:46 UTC
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?
Comment 25 Tim Starling 2009-05-09 04:08:46 UTC
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.
Comment 26 Karun 2009-05-09 12:24:26 UTC
I have added the keyword upstream.
The upstream bug is here  http://bugs.php.net/bug.php?id=48181
Comment 27 Karun 2009-05-09 21:04:56 UTC
*** Bug 18742 has been marked as a duplicate of this bug. ***
Comment 28 Karun 2009-05-10 03:12:14 UTC
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. 
Comment 29 Tim Starling 2009-05-10 15:28:11 UTC
(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.
Comment 30 Karun 2009-05-10 19:37:56 UTC
(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.
Comment 31 Karun 2009-05-10 20:31:29 UTC
(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

Comment 32 Daniel Ziegenberg 2009-05-11 06:47:42 UTC
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.
Comment 33 Daniel Ziegenberg 2009-05-11 06:53:03 UTC
Created attachment 6106 [details]
requested phpinfo output from comments #c23
Comment 34 John Doyle 2009-05-11 10:06:11 UTC
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'.
Comment 35 John Doyle 2009-05-11 10:28:34 UTC
This bug in redhat's bugzilla seems to be the same problem I'm having: https://bugzilla.redhat.com/show_bug.cgi?id=492825
Comment 36 Karun 2009-05-11 10:33:25 UTC
(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.

Comment 37 John Doyle 2009-05-11 10:36:06 UTC
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 :-(
Comment 38 Tim Starling 2009-05-11 11:20:40 UTC
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.
Comment 39 Tim Starling 2009-05-11 11:49:04 UTC
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;
}
Comment 40 Etienne Massip 2009-05-19 16:35:30 UTC
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 !
Comment 41 Alexandre Emsenhuber [IAlex] 2009-07-21 09:52:28 UTC
*** Bug 19479 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links