Last modified: 2012-04-12 13:55:47 UTC
Product Version MediaWiki 1.16.4 PHP 5.3.6-pl0-gentoo (cgi-fcgi) PostgreSQL 9.0.3 (but also seen with 8.4) EXECUTING THIS API QUERY (but under PostgreSQL): http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcend=2010-05-06T14:31:51Z&rclimit=1&rcprop=title|timestamp&rctype=edit&format=xmlfm RETURNS THIS ERROR VIA API: error code="internal_api_error_DBUnexpectedError" info="Exception Caught: A database error has occurred Query: SELECT rc_timestamp,rc_namespace,rc_title,rc_cur_id,rc_type,rc_moved_to_ns,rc_moved_to_title FROM recentchanges WHERE (rc_timestamp>='20100506143151') AND rc_deleted = '0' AND rc_type = '0' ORDER BY rc_timestamp DESC LIMIT 2 Function: ApiQueryRecentChanges::execute Error: 1 ERROR: invalid input syntax for type timestamp with time zone: "20100506143151" LINE 1: ...title FROM recentchanges WHERE (rc_timestamp>='201005061... WHICH IS LOGGED AS: ==> /var/log/php5-cgi.log <== [14-Jun-2011 05:20:26] PHP Warning: pg_query() [<a href='function.pg-query'>function.pg-query</a>]: Query failed: ERROR: invalid input syntax for type timestamp with time zone: "20100506143151" LINE 1: ...title FROM recentchanges WHERE (rc_timestamp>='201005061... ^ in /var/www/localhost/htdocs/mediawiki/includes/db/DatabasePostgres.php on line 584 MY FIX to includes/api/ApiBase.php: case 'timestamp': if ( $multi ) { ApiBase::dieDebug( __METHOD__, "Multi-values not supported for $encParamName" ); } $value = wfTimestamp( TS_UNIX, $value ); if ( $value === 0 ) { $this->dieUsage( "Invalid value '$value' for timestamp parameter $encParamName", "badtimestamp_{$encParamName}" ); } // $value = wfTimestamp(TS_MW, $value); //// MCA. Above fails on PostgreSQL. It works if space inserted between date and time, // thus "20100506 143151". But here is an easier fix: $value = wfTimestamp( TS_POSTGRES, $value ); break;
Can you check if the problem still occurs in 1.17.0rc1? I recall having fixed a similar issue, but I don't remember if it was specifically with recent changes.
Changing the timestamp type in ApiBase.php is a bad idea. Changing it to TS_POSTGRES is even worse, because that'll break on non-Postgres backends. The *proper* way to do this is for API modules to transform user-provided timestamps with $db->timestamp(), which does a DB-specific timestamp transformation. It so happens that the default timestamp format (TS_MW) is also the DB timestamp format for the default DB backend (MySQL) so these issues aren't typically noticed.
Thank you for the quick reply. @Bryan, I am unable to test > 1.16.4. I can only confirm that the fault was in some earlier versions. I was patching it for a while without reporting it. @Roan, 'fix' is the wrong word then, I only hacked it to make it work for me. I appreciate the PostgreSQL support. It's mostly solid. If you think it might help, I could file a bug/feature request for improved testing of DB compatibility. Automated tests might be a more efficient way to detect faults like these. Please let me know.
> I appreciate the PostgreSQL support. It's mostly solid. If you think it might > help, I could file a bug/feature request for improved testing of DB > compatibility. Automated tests might be a more efficient way to detect faults > like these. One good way to help us would be to check out http://www.mediawiki.org/wiki/Database_testing and add anything you think we've missed.
Thanks Mark. I added a new item: http://www.mediawiki.org/wiki/Database_testing?action=historysubmit&diff=410735&oldid=410591
In reply to: > Reedy <sam@reedyboy.net> changed: > > What |Removed |Added > ----------------------------- > Priority|Normal |Low I can survive by patching the code as a workaround. I raised the severity to "major", which seems to be correct: "Prevents function from being used, but a work-around is possible" http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html
Fixed in r99138