Last modified: 2012-08-04 20:49:06 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 15148 - Special:BlockIP broken in PostgreSQL
Special:BlockIP broken in PostgreSQL
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
1.12.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres
  Show dependency treegraph
 
Reported: 2008-08-13 06:34 UTC by Tim Starling
Modified: 2012-08-04 20:49 UTC (History)
3 users (show)

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


Attachments

Description Tim Starling 2008-08-13 06:34:42 UTC
Report on IRC:

"I've just installed a new instance of mediawiki. I created a test user called "Test" by registering with that name. Now, I've logged in as the administrator user and I'm trying to block the test user, but the blocking interface says the user is already blocked. However, the block list says there's nobody there, and indeed the user doesn't seem to be blocked in any way. I'm using mediawiki 1.12 and PostgreSQL 8.3, anyone know what might be wrong?"

Sounds like a DBMS issue to me.
Comment 1 OverlordQ 2008-08-13 06:51:48 UTC
==
SQL: INSERT /* Block::insert OverlordQ */ INTO ipblocks (ipb_id,ipb_address,ipb_user,ipb_by,ipb_by_text,ipb_reason,ipb_timestamp,ipb_auto,ipb_anon_only,ipb_create_account,ipb_enable_autoblock,ipb_expiry,ipb_range_start,ipb_range_end,ipb_deleted,ipb_block_email) VALUES ('4','Over1ordQ','15','1','OverlordQ','test','2008-08-13 06:38:50 GMT','0','0','1','','2008-08-13 08:38:50 GMT','','','0','')
SQL ERROR (ignored): ERROR:  invalid input syntax for integer: ""
==

Looks to be the query causing that.  
Comment 2 Max Semenik 2008-08-13 07:20:34 UTC
Apparently, it doesn't like that empty strings are inserted into boolean columns ipb_enable_autoblock and ipb_block_email.
Comment 3 Greg Sabino Mullane 2008-08-20 17:56:40 UTC
Max: those columns were changed from boolean to smallint: if they are still boolean for you, run updaters.php.
Argh, I wish Mysql has a real boolean type. I'll see about having the query not assume that the database backend will convert an empty string to the number 0.
Comment 4 Greg Sabino Mullane 2008-08-20 18:04:57 UTC
Brent, can you try this on the latest revision? Looking over Block.php in subversion, I'm not seeing any place that would cause mEnableAutoblock to NOT be 0, so I'm curious how the statement you showed would have got generated unless it's from an older version.
Comment 5 OverlordQ 2008-08-20 18:13:45 UTC
Problem does still exist in SVN.

Here's from debug log and postgres log:
http://pastebin.ca/QGazBKyC

password is: mw.
Comment 6 Greg Sabino Mullane 2008-08-20 18:21:10 UTC
Ah, I think I found it. Line 64 of specials/SpecialBlockip.php:

$this->BlockEnableAutoblock = $wgRequest->getBool( 'wpEnableAutoblock', $byDefault );

I'm guessing getInt would be more appropriate here, but I'm not going to change that until someone can weight in from the mysql sie of things.
Comment 7 Tim Starling 2008-08-21 01:25:33 UTC
In MySQL we use tinyint(1) columns for booleans. It should definitely be inserting numbers into them, not empty strings. If PostgreSQL is using integers consistently, then perhaps we could fix this for both DBMSes in Database::addQuotes()?

if ( is_null( $s ) ) {
    return 'NULL';
} elseif ( is_bool( $s ) ) {
    return intval( $s );
} else {
    return "'" . $this->strencode( $s ) . "'";
}

Comment 8 Greg Sabino Mullane 2008-08-21 13:11:00 UTC
Tim: I really like that solution. Ideally we'd have Postgres using true BOOLS and map things to 'true' and 'false', but I think it's early days for that, as there are lots of other places in the code that assumes bool==tinyint.

Brent, I made the above change to r39763, please give it a whirl.
Comment 9 OverlordQ 2008-08-21 19:39:27 UTC
It's kinda fixed, the query works but there's still oddities going on.

As can be seen here, we're starting with an empty blocklist: http://toolserver.org/~overlordq/ipblocks.txt

Now let me block the test account. From the debug log: http://pastebin.ca/1180966

However, after form submission, Special:BlockIP says: "TestUser" is already blocked. But according to the ipblocks table, it's the first block: http://toolserver.org/~overlordq/ipblocks2.txt


Comment 10 Tim Starling 2008-09-06 07:17:52 UTC
Fixed in r40515, backported to 1.13 in r40517.

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


Navigation
Links