It's annoying and pointless. Instead, have MWException write them to
standard output where we can catch them with ob_start().
Bug: T170028
Bug: T170029
Change-Id: Icd99c1c39d4a30d78c511d33948ef639e1b92455
Named locks are session-level constructs and this transaction agnostic.
Also make lockIsFree() a bit more consistent when the thread has the
lock itself.
Change-Id: Ief51196161bbc50c798740f3c738fd0e39880508
Done using the PhpStorm refactor->rename tool.
Also move "defaultBigSelects" declaration to DatabaseMysqlBase
as no other classes uses that.
Change-Id: I424a2d9815de3a5d4cca2522f3db23a5efe6b592
This was added in r19879 (3de6fd8c8) with no provided use case.
There also appears to be nothing exploiting this.
Change-Id: I1641d4ed16d612ab6f08ee1eeca1580af73888bf
This pattern is already used elsewhere and seems like a more efficient
way to acquire locks in a non-blocking way.
Change-Id: Idb369e7cb03b793d5f8295e956fecd8d1f849e17
It is off by default, it's very rarely used (GitHub finds four config
users setting it true), it has over time had fatals going unnoticed or
fixed for years. Let's just kill it.
Change-Id: Idac2341ed7ecf053ee84069df657e424e50b896c
wfDebugBacktrace doesn't work very will with logstash.
The whole message ends up being too long and the log ends
up in the 'jsonTruncated' channel.
Instead use wfBacktrace which will be smaller as it just gives
us a string.
Change-Id: I5309ac2ad4592fb6dbb1474526d382893fb7e6c1
If !$this->mBaseRevision then the code to populte $this->mBaseRevision
is run.
This code either calls Revision::newFromId or Revision::loadFromTimestamp
both of which are documented as being able to return null.
As a result EditPage::getBaseRevision can alos return null.
Bug: T187378
Change-Id: I60ad9ddcfbe6e1060cab1ad6aa2194c1a3406cbf
* Instead of returning all zeroes, just use zero for the
negative values in the row.
* Allow large numbers since the fields are BIGINT.
* Clean up the return types to truly be integers.
* Respect the $groups argument in SiteStatsInit::getDB().
Bug: T186947
Change-Id: I51fdc45124c12aba114540fc0ec66a3e63d61e09
Each expired row has to be fetched from the user_groups table, deleted
from that table and added to the user_former_groups table. Per Jaimes
request, let's not do this for all rows at once but for smaller chunks
and wait for replication to catch up after each chunk has been
processed. In addition the function to purge the expired rows now sets a
lock so that there won't be multiple concurrent runs.
Also, cleaning this table up isn't urgent and thus should be done in a
job and not a deferred update, so let's move it there.
Bug: T176754
Change-Id: I671d4b9d09677a2f474477ba7fea33a44d6318aa
