That query is wrong, JOIN pagelinks ON pagelinks.pl_target_id = page.page_id won't work. pl_target_id is not FK to page_id, pl_from is but it depends on your usecase.

We could not find a way to fo "left" using Wikimedia ORM and we used "SUBSTR" instead. Is that ok? or can you suggest a better method to use

Hi, I responded in the patch. hope that'd be useful for you.

Honestly, I think this should be declined as this is a x/y problem. I understand you need to see content of the whole law in one place, but that doesn't mean size of page should increase. A proper solution here is to have a way to see a full book or set of pages in one place. Think of google docs or a PDF file. That is doable but needs to resourced and prioritized and implemented. That can be useful in many other areas too (being able to read a large book in a way of "infinite scroll" on the wiki)

Does reducing the key sizes (from 256 to 128 for AES and 386 to 256 for SHA) sound good to people? We can deploy it temporarily and measure the impact.

Awesome thank you!

While non-Latin characters take twice as space, since Arabic and Hebrew scripts don't write short vowels (unless for children or disambiguation), the average letter per word is much lower than Latin scripts. In other words, even if you translate it to English, it'll just go above the threshold.

In T275319#9813641, @Fuzzy wrote:

I wish to avoid the discussion what "should be" the limit of the page length, in characters.

Yes. s5 wikireplica needs to actually get the alter (will be over in an hour) and then a run of maintain views. Be patient. It will be resolved soon.

A possible solution to this problem is this: T365303: Move update of category members count to CategoryMembershipChangeJob

Yeah, this would fix that bug automatically but maybe it's not a good solution. Depending on what mediawiki team thinks about this.

Okay cool. Thanks for checking.

In T365327#9811326, @Vgutierrez wrote:

Chacha20 is faster than AES when both are running without hardware acceleration. If AES-NI is present, AES is faster. This is also considered by clients to choose their ciphersuite suite to be sent to the server as part of the ClientHello

Stupid note: In my phone, it still prefers AES256. Maybe my client for whatever reason doesn't support ChaCha20 or it thinks it's strong enough to just go with AES instead. But I will try to confirm SSL_OP_PRIORITIZE_CHACHA is working.

Just to make it clearer, ChaCha20 is still that's not my preference. I prefer simply reducing the key size for AES and SHA instead.

I should have been clearer, Meta prefers it everywhere including desktop. It's the top of ciphersuite by default including where it's not the top of client's cipher suite too. Maybe because fb/instagram is heavily targeted for mobile users.

We can also consider preferring ChaCha20 everywhere as well like Meta websites.

Also noting that I'm talking about the lock in ::acquireAndInsertTerms() and not the one on ::deleteTermsWithoutClean() as the latter happens much less frequently and doesn't lock contention from what I'm seeing.

I agree that the pruning part needs to be rethought and revamped but I'm failing to see how it's connected to this problem. This is explicitly about locking the rows in wbt_item_terms which is the head. Let's say for Q1234 you have this:

+------------+--------------+----------------------+
| wbit_id    | wbit_item_id | wbit_term_in_lang_id |
+------------+--------------+----------------------+
|  767752395 |     1234 |                    5 |
| 6682347558 |    1234 |                  172 |
|   95594787 |      1234 |                  192 |
|   34102141 |       1234 |                  237 |
|  561818268 |     1234 |                  274 |
+------------+--------------+----------------------+

It deals with depools and repools but not new clusters which is rare. Sigh.

oh lovely
let me restart some scripts

I thought it might have not been deployed, but it is: https://phabricator.wikimedia.org/T362786#9794065

in etcd, they should have been ignored
let me check

Looks so cool already!

<3

I leave that to Manuel. I take care of the mw side of things.

Caused by migration to SQB. cc @DannyS712 @Umherirrender

At least we know it's not going to break replication again but someone needs to fix the underlying problem. I might get to it eventually but no cookie licking so if someone else is willing to, sure.

What would be the usecase for upload from other sites to non-commons. Assuming they are all fair use images (otherwise they should go to commons), maybe we shouldn't allow it? I know there are some discrepancies between copyright laws and some wikis allow some images that wouldn't be allowed in Commons but that's still quite a marginal usecase (unless I'm missing something super obvious). e.g. for T364288: Server-side upload request for hinnk why it's not being uploaded to commons?

In T364617#9797152, @Umherirrender wrote:

I find it helpful to get all pages linking to a subset, most usable with prefix parameter.

You could reorder the list of extensions to be loaded in production, it has been before for the exact same problem but 1- It's not sustainable 2- it might break other things.

Third one from third user:

User properties over 1M rows in enwiki, maybe that'd be helpful for clean up:

mysql:research@s1-analytics-replica.eqiad.wmnet [enwiki]> select up_property, count(*) from user_properties group by up_property order by count(*) desc limit 100;
+-----------------------------------------------------+----------+
| up_property                                         | count(*) |
+-----------------------------------------------------+----------+
| echo-subscriptions-email-page-review                | 19153xxx |
| echo-subscriptions-email-edit-thank                 | 19033xxx |
| echo-subscriptions-web-article-linked               | 18891xxx |
| echo-subscriptions-email-mention                    | 18869xxx |
| echo-subscriptions-web-reverted                     | 18845xxx |
| echo-subscriptions-email-article-linked             | 18493xxx |
| popups                                              | 13718xxx |
| skin                                                | 10012xxx |
| thumbsize                                           |  9307xxx |
| rememberpassword                                    |  8187xxx |
| visualeditor-autodisable                            |  8005xxx |
| visualeditor-hidebetawelcome                        |  6998xxx |
| VectorSkinVersion                                   |  4377xxx |
| echo-subscriptions-email-dt-subscription            |  3708xxx |
| watchcreations                                      |  3468xxx |
| growthexperiments-homepage-pt-link                  |  2730xxx |
| growthexperiments-homepage-enable                   |  2730xxx |
| growthexperiments-help-panel-tog-help-panel         |  2717xxx |
| growthexperiments-homepage-variant                  |  2714xxx |
| growthexperiments-tour-help-panel                   |  2714xxx |
| growthexperiments-tour-homepage-mentorship          |  2704xxx |
| discussiontools-autotopicsub                        |  2575xxx |
| watchlisttoken                                      |  2527xxx |
| echo-subscriptions-web-wikibase-action              |  2492xxx |
| timecorrection                                      |  2320xxx |
| date                                                |  2217xxx |
| growthexperiments-homepage-mentorship-enabled       |  2099xxx |
| nickname                                            |  2048xxx |
| visualeditor-editor                                 |  1910xxx |
| growthexperiments-tour-homepage-discovery           |  1701xxx |
| homepage_mobile_discovery_notice_seen               |  1619xxx |
| gettingstarted-task-toolbar-show-intro              |  1351xxx |
| growthexperiments-tour-homepage-welcome             |  1294xxx |
| visualeditor-hideusered                             |  1260xxx |
| enotifusertalkpages                                 |  1127xxx |
| growthexperiments-homepage-se-filters               |  1089xxx |
| growthexperiments-tour-newimpact-discovery          |  1027xxx |
| variant                                             |  1015xxx |
| compact-language-links                              |  1008xxx |

{{done}}
https://lists.wikimedia.org/postorius/lists/wikipedia-pl-admins.lists.wikimedia.org/

We will go with the name wikipedia-pl-admins to be consistent with other wikis. Hope that's fine with you.

@Umherirrender I hope to actually deprecate the endpoint: T364617: Deprecate and remove alllinks API endpoint

In T120242#9792008, @Ottomata wrote:

So there is no real "source of truth".

So it is quite possible that we might even lose canonical data due to inconsistencies between master and its candidate. It is extremely rare but not out of question.

Wow that is very interesting!

Does that mean that it is possible (although unlikely) that a suppression of PII may be suppressed in one master but not the other? Or a page deleted in one master but not the other?

if you used virtual domains, yes.

That code is used in other places now, making the roll back more complicated. The fix is straightforward.

Ah found it. Sneaky bug. I patch it now.

All of these errors are clearly because virtual domains is now broken. cc @Tgr I debug and see what I can find.

This is very likely caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1024973/3/includes/libs/rdbms/lbfactory/LBFactory.php a refactor we did on virtual domains, but I can't see how. I'm not spotting any obvious mistakes (I dig deeper). If you do, please let me know.

I think I know what's going on. Give me a bit.

Hi @Urbanecm is this resolved or you're still seeing stuff?

Feel to create a separate request for mailing list for general matters of English Wiktionary. You can bring it up in your wiki's village pump to see how much of support it's going to get.

It would be great if a designer could sit and take a look at the design of FR. It has four modes via matrix of: Low profile vs non-low profile and simple UI vs non-simple UI. Which I would really like to merge and unify.

In T362646#9791335, @SimoneThisDot wrote:

Do you know if there is a simple way to "fill up" a local database with dataset? We want to make sure the code we run is as performant as possible, and we do not know how to achieve this with just the local database

We all have had such misfortunes! Fixing the issue in mw is rather easy, we should just drop the code piece, bump the number in several places, update the schema validation and update tests. Here is an example https://gerrit.wikimedia.org/r/c/mediawiki/core/+/464768

Pulling it in mwdebug and reducing the threshold to four connection led to this:

In T364587#9784757, @stjn wrote:

Seems like @Jdlrobson in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1020418 while fixing T361671. Merged by @Ladsgroup.

Making such an unwarranted (and unannounced!) breaking change while fixing a routine issue is really strange. (edit: better wording)

We should get rid of that part and bump the XML version as Daniel suggested. Wanna do it?

Haven't checked logged out, what I get is logged in users.

In T364691#9790207, @Vgutierrez wrote:

we had a big spike of 503s on eqiad/drmrs/esams yesterday during EU morning: https://grafana.wikimedia.org/goto/J4YqQuYIR?orgId=1:

Oh no, that would explode the database and appservers if you query for an active editor. you can just do a left() in the sql. Just query group by left(rev_timestamp, 6) and get the count. I know it won't work with PG but it shouldn't be too hard to fix :P

if you want a general mailing list for English Wiktionary then it should be wiktionary-en@. We can have both.

It's not just the privacy. For example, we want to eventually implement uploading from URLs via chunks which means a file being uploaded can have many stashed files instead of one. So this is about the encapsulation of how mw works.

Second: Should be public or private?

Hi, you mean English Wiktionary admins or admins of all wiktionary projects? If the former, then it should be wiktionary-en-admins@lists.wikimedia.org (see https://meta.wikimedia.org/wiki/Mailing_lists/Standardization)

It happens. I wish we had better monitoring to see jumps like this. I actually have a plan for a SLO that would have failed with such regressions forcing us to look at it. Hopefully soon.

I have somewhat of a plan to deploy this without breaking the footer. If someone is willing to help shepherd this to production, please let me know. Maybe @Jdforrester-WMF ? <3

If we fix the sanization in the patch, this will be the result:

Avoiding cookie licking

FWIW, for each section we have a master and a "candidate master". We always swap them when we need to do maintenance. So there is no real "source of truth". There are two (not to mention we change candidate masters from time to time if there are hw issues, refreshes, etc.). So it is quite possible that we might even lose canonical data due to inconsistencies between master and its candidate. It is extremely rare but not out of question.

Here is the load on the databases going down:
(deploy finished at 7:56)