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. PROPOSED FIX: 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
