Last modified: 2012-08-04 20:48:53 UTC
When testing Gerrit change #3841 noticed that when I forgot to run update.php
the query fails as expected:
Query trunk (90) (slave): INSERT /* Block::insert Saper */ INTO "ipblocks" (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,ipb_allow_usertalk,ipb_cause,ipb_id) VALUES ('Test5','2','1','Saper','Bez autoblock','2012-03-28 18:50:57 GMT','0',0,0,0,'2012-03-29 18:50:57 GMT','','','0',0,0,NULL,'137')
Query trunk (91) (slave): ROLLBACK
SQL ERROR (ignored): ERROR: column "ipb_cause" of relation "ipblocks" does not exist
LINE 1: ...nd,ipb_deleted,ipb_block_email,ipb_allow_usertalk,ipb_cause,...
Query trunk (92) (slave): BEGIN
Transaction state changed from IDLE -> TRANS
But the error is ignored due to generic workaround for errors encountered during INSERT IGNORE. (This one is from Block.php:444).
The MediaWiki says then everything is OK and even this block gets logged in the log, but is not active.
HOW TO REPRODUCE:
Apply Gerrit change #3841 patchset 3 to 8824515e571eadd4a63b09e1331f35309315603f
and try to block some user. The query will fail but MediaWiki says all is fine.
I would propose to narrow down ignorable query failures only to violations of primary keys.
Another thing is it would be good to check if log entry gets rollbacked too in case of fatal error.
Fixed in Gerrit change #3977