Last modified: 2014-08-20 19:49:26 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 34372 - New User hook broken for PG, breaks normal logging
New User hook broken for PG, breaks normal logging
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
All All
: High normal (vote)
: Future release
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: postgres
  Show dependency treegraph
Reported: 2012-02-13 15:29 UTC by OverlordQ
Modified: 2014-08-20 19:49 UTC (History)
6 users (show)

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


Description OverlordQ 2012-02-13 15:29:13 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.
Comment 1 Antoine "hashar" Musso (WMF) 2012-03-02 22:05:49 UTC
Looks like it is a regression in the way we pass page_id to some new user hook.
Comment 2 Marcin Cieślak 2012-03-10 22:29:14 UTC
Added to 1.19 tracking per bugmeister's email.
Comment 3 Marcin Cieślak 2012-03-11 21:37:39 UTC
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?
Comment 4 Marcin Cieślak 2012-06-15 00:05:24 UTC
Asher - could you possibly to comment on this schema change?12
Comment 5 Asher Feldman 2012-06-15 19:26:38 UTC
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.

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.

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