Last modified: 2012-08-04 20:49:06 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T11916, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9916 - On PostgreSQL 8.1, search does not work.
On PostgreSQL 8.1, search does not work.
Status: RESOLVED DUPLICATE of bug 9908
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
PC Linux
: High critical (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: postgres
  Show dependency treegraph
Reported: 2007-05-15 07:50 UTC by Stephen Martindale
Modified: 2012-08-04 20:49 UTC (History)
0 users

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


Description Stephen Martindale 2007-05-15 07:50:42 UTC
I recently upgraded my wiki (PostgreSQL back-end) to version 1.10.0 using the
official upgrade method - i.e. running the update.php script with the PHP 5.2
CLI. The Wiki works but the search fails. This is a critical bug because a wiki
is useless without search!

I enabled $wgShowExceptionDetails and found more information on the error:
"ERROR: unrecognized normalization method: 5". A quick read of the query showed
that the script was trying to send "5" as the "normalization" parameter to
Tsearch2's "rank()" method. (Parm. 3)

Some research into TSearch2 shows that only three options are available for this
    * 0 (the default) ignores document length.
    * 1 divides the rank by the logarithm of the length.
    * 2 divides the rank by the length itself. 
(Confirming my suspicions, I've used TSearch2 before...)
(Cut and Paste from

Thinking that OpenFTS might have introduced more normalization options, I
checked the OpenFTS documentation. This did not reveal a solution - OpenFTS'
docs agree with the Tsearch2 docs.

Grep'ping around inside MediaWiki reveals the offending line to be line 144 of
includes/SearchPostgres.php which is hard-coded to send a value of 5 here.

I immediately suspected a bug introduced by the upgrade process (as I said, I
had upgraded (from 1.8, I think)) and checked the original archive of files I
downloaded from SourceForge - the file is identical. This bug was not caused by
a failure to update this individual file. While checking the original archive, I
did notice the existance of an includes/SearchTsearch2.php file. I was not sure
what that file was there for, so I examined it.

Within includes/SearchTsearch2.php, the rank() method is called with only 2
parameters. Hmm... interesting...

I tried two solutions.

First, I changed this "5" (line 144) to "2" (a non-default value I chose
willy-nilly from the three available choices) and saved
includes/SearchPostgres.php. The search succeeded. This solution poses three
    a) Why is there a 5 in the released code? Is it a genuine bug or am I
missing something?
    b) What *should* this value be, assuming it should not be 5?
    c) Could the fix be this simple? (That was *way* too easy.)

Secondly, I tried to find where "SearchPostgres" was being specified as the
search engine (hook) to use, intending to change it to SearchTsearch2 and see
what happens. I found the only reference to "SearchPostgres.php" on line 156 of
includes/AutoLoader.php. Killing this line broke the search function entirely.
(class 'SearchPostgres' not found.) Duh. (Spontaneous, quirky wish: must create
aliases for grep, called "grp" and "gre") Replacing the line with:
    'SearchTsearch2' => 'includes/SearchTsearch2.php',
... also did not work, until I changed 'SearchPostgres' to 'SearchTsearch2' on
line 215 of includes/SearchEngine.php. Sadly, while this caused the search to
run, no results where returned for my search terms.

Clearly the only solution is to change the 5 to something else (0, 1 or 2) on
line 144 of includes/SearchPostgres.php.

Am I missing something?
Can someone confirm this bug and this proposed solution?
What *is* the correct value? 0, 1 or 2?

P.S. Please forgive the stream-of-consciousness debugging technique. It works.
Comment 1 Greg Sabino Mullane 2007-05-15 18:19:46 UTC

*** This bug has been marked as a duplicate of 9908 ***

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