Fixed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1101977

I still have this probably locally and have for years. There is probably some bad assumption that some postgres sort/collation default will have a certain value.

One question is whether I should just add an autoincrement ID. It would make the DELETE queries for expiration simpler. Originally, I wanted to keep the schema support both regular and circular replication. Given the operational fun involved with the later, we could probably just bake in the non-circular replication assumption in exchange for simple IN() clause deletion instead of using factorConds().

In T368289#10195606, @HCoplin-WMF wrote:

That seems reasonable. @aaron -- any concerns with closing for now?

In T366640#10192800, @HCoplin-WMF wrote:

@aaron -- please confirm this was fixed by related patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1075067 (and update if it doesn't :) )

Closing, since the log spam is gone. The remaining patch falls under the "possible general improvements" category.

I haven't seen this error in logstash lately. I know that an error like this used to occur and was fixed in 65aa3c0a3e3. Presumably, someone changed the load weights in etcd while the script was running. This error shouldn't happen, though the script can be restarted if it does still occur.

In T315664#9100832, @Ladsgroup wrote:

Actually, what if we completely deprecate and remove this method and also flushPrimarySnapshots together and move the code simply to commitAndWaitForReplication if not already there? I don't think they would make a big difference in the time to run a job or something like that.

Actually, it looks like wmfApplyEtcdDBConfig() already hard codes 0 load when using remote servers for the writer index. This explains the low log rate. So the only thing left to do here is just disable the primary fallback logic for the 'is static' case in ExternalStoreDB.

Even without the fallback logic, the setup seems odd. Since the es5 cluster config has 100 weight for the writer index, DB_REPLICA servers are likely to result in writer index handles. That fine except that $wmgRemoteMasterDbConfig will be used in codfw to point the writer index to the remote servers. Maybe etcd.php should ignore $crossDCLoads if $lbFactoryConf['templateOverridesByCluster'][$mwLoadName]['is static'] is set.

The logging code should check hasStreamingReplicaServers(), though it will then incidentally ignore cross-DC queries to static clones servers.

Isn't the fallback useless in this case, since there won't be anything on the primary that is not on the replica? Also, why is some non-existing blob being referenced so much? From etcd.php in mediawiki-config, it looks like DB_PRIMARY will still use a server in the primary datacenter, even for 'static' clusters, meaning that it's still a cross-DC query sometimes. This makes it seem like the warning is legitimate.

Looks like ApiEditStash still wasn't done, just PageEditStash.

In T199393#10089744, @Krinkle wrote:

Let's step back a bit though. Why would someoneone even want to do a SELECT … LOCK IN SHARE MODE query? At face value, it looks like the intention may be to prevent the row from being changed (if it exists) and prevent anyone else from creating it if it doesn't exist. There's a few problems with that.

This might interfere with any use case that involves all of:
a) Batched reads from a DB_REPLICA transaction with a point-in-time view snapshot.
b) An assumption that DB_REPLICA will only get a replica server (e.g. there 1+ replicas and the primary has 0 load balancer weight)
c) Batched writes (involving replication waits). commitAndWaitForReplication() would keep flushing the DB_REPLICA view snapshot.

In T283766#7118076, @tstarling wrote:

So here's what I'm thinking:

• Make the $restriction parameter to SpecialPage::__construct() accept an array
• Introduce isEnabledByConfig(). Let the subclass return a message somehow if it is disabled.
• A generic overridable method, with a suggestive name, to attract the random chunks of authorization-like controller logic.
• A new overridable method to replace subclass execute() functions. Empty by default and aspirationally tending towards being abstract.
• SpecialPage::execute() would aspirationally tend towards being final rather than being abstract and would call all these new overridable methods.