Last modified: 2014-08-20 19:49:26 UTC
CheckUser is broken wrt Postgres and the new user hook. PG has a foreign key constraint on cu_page_id to an entry in the page table, however on new users it tries to enter page id 0 which doesn't exist. I'm fairly sure this worked fine before, so I dont know what or when the behavior changes. This completely breaks the new user log.
Looks like it is a regression in the way we pass page_id to some new user hook.
Added to 1.19 tracking per bugmeister's email.
Can we check how much regression is this? PostgreSQL allows NULL in cuc_page_id but does not allow 0 because of constraint. MySQL the reverse - allows 0 but it's NOT NULL. We even explicitly insert zero in the new extension code, but I am not sure what's coming via hooks. We are also using some other hooks (e.g. bug 19963 fixed with r88258 as well as some new hooks), so probably it's best to detect zero and covert it to NULL. I would tend to change cuc_page_id to NULL on MySQL (yeah, on this means on Wikimedia too) plus fix the code where necessary. Is this okay with everyone?
Asher - could you possibly to comment on this schema change?12
I think having cuc_page_id default to NULL makes more sense, and enwiki currently has slightly over 1 million rows in cu_changes where cuc_page_id = 0, out of ~16mil rows total. That said, it is only until relatively recently (in the history of mysql) that NULL values have been allowed for integer types. http://bugs.mysql.com/bug.php?id=44243 That's why you'll see DEFAULT NULL in the char fields, but NOT NULL DEFAULT 0 for the ints. Changing this is ok wrt the version of mysql in production at wmf, but would require increasing the minimum required version of mediawiki beyond what it currently is.
