[06:29:16] <wm-bot>	 !log lucaswerkmeister@tools-bastion-13 tools.ranker deployed e059817c66 (l10n updates: fr, he, pt)
[06:29:19] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.ranker/SAL
[06:31:19] <wm-bot>	 !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed d1f4beb35e (l10n updates: af, ru, tr)
[06:31:20] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL
[06:33:59] <wm-bot>	 !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed cc28ff0494 (l10n updates: et, it, nn, pt-br, ru)
[06:34:00] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL
[07:03:13] <wm-bot>	 !log lucaswerkmeister@tools-bastion-13 tools.quickcategories deployed 5b65c99d03 (upgrade dependencies, including mwparserfromhell 0.7.2)
[07:03:16] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.quickcategories/SAL
[08:19:01] <wm-bb>	 <iamnotnothamish> hi, I run tools.hamishbot and possibly I ruined the toolsdb again as I have to wait for meta clock when introspecting
[08:37:55] <dcaro>	 iamnotnothamish: can you elaborate?
[08:48:08] <wm-bb>	 <iamnotnothamish> hmm, I use Datagrip by JetBrains to visualise database, and when I tried to refresh database structure, the Datagrip stuck at "Introspecting database at level 1: processing 1 regular schemas completely", then I tried "show full processlist", it outputs a process with state "waiting for table metadata lock", I cannot use Datagrip to visualise db anymore but I can
[08:48:08] <wm-bb>	 still view the data
[08:48:33] <wm-bb>	 <iamnotnothamish> does that make sense?
[08:53:19] <wm-bb>	 <iamnotnothamish> and I cannot find any other process except the one I mentioned above
[08:59:35] <dcaro>	 what database is it?
[09:01:40] <wm-bb>	 <iamnotnothamish> toolsdb, s53993__prc_admin_p, and I just found it turns normal......
[09:03:16] <dcaro>	 so it sorted itself out?
[09:04:12] <wm-bb>	 <iamnotnothamish> currently yes
[09:04:44] <wm-bb>	 <iamnotnothamish> shall we figure out what caused that?
[09:07:17] <dcaro>	 does it happen often? I saw no disruption for other tools (did not look too deeply though, and it might have been gone by the time I checked), so if it does not bother you much we can wait see if it happens again/becomes a problem
[09:11:40] <wm-bb>	 <iamnotnothamish> alright, just wait then
[09:11:50] <wm-bb>	 <iamnotnothamish> thx tho
[09:12:05] <dcaro>	 np :), let me know if it happens again
[09:32:50] <wm-bb>	 <iamnotnothamish> dcaro: it comes back again, and I think it's my database's fault...
[09:33:59] <wm-bb>	 <iamnotnothamish> if I wait the command, it can sort itself out after few minutes, but we cant wait it everytime right?
[09:38:45] <wm-bb>	 <iamnotnothamish> https://phabricator.wikimedia.org/P78767, this is what Datagrip tried to do
[09:46:27] <dcaro>	 I see, can you open a task to investigate further?
[09:46:51] <dcaro>	 It seems that the issue might be the `information_schema.views`
[09:46:58] <dcaro>	 (the join with it)
[09:48:05] <wm-bb>	 <iamnotnothamish> can you try this select, to see if this is a common issue?
[09:49:25] <dcaro>	 I did yes, and it's very slow, the `information_schema.tables` part of it is ok, 11k tables, but for example when doing `select count(*)` on the `information_schema.views` it takes a long time
[09:50:00] <dcaro>	 maybe you can configure the Datagrip to not pull in the views as a workaround, but we might be able to do something to the views to make them more easily queriable
[09:50:11] <wm-bb>	 <iamnotnothamish> ah okay, looks like it's not me ruined the database again xd
[09:50:22] <dcaro>	 (not a db expect, so will have to investigate, that's why the task :) )
[09:50:57] <wm-bb>	 <iamnotnothamish> np, will do shortly
[09:51:42] <dcaro>	 yep yes, ideally there should not be any problem with anyone running long queries and such, they should just be killed if they can't be processed, without affecting other users, so even if you do a "wrong" query it should not be a problem (again ideally xd)
[09:51:45] <wandering_blue_h>	             Home Address: Comrie, 8 Southampton Road, Fareham, Hampshire, United Kingdom, PO16 7DY
[09:59:34] <dcaro>	 took 43s just to count the views
[09:59:40] <dcaro>	 https://www.irccloud.com/pastebin/olJ5a1dF/
[09:59:53] <dcaro>	 gtg for a bit, be back later
[10:16:23] <wm-bb>	 <iamnotnothamish> took 11min and 43s exactly...
[10:21:22] <dcaro>	 Yep yep xd
[15:46:22] <wm-bb>	 <IVeertje> The quickstatement app is offline for me can it please be rebooted
[15:51:57] <dcaro>	 looking
[15:52:55] <dcaro>	 IVeertje should be back online, can you check?
[16:05:20] <wm-bb>	 <IVeertje> Yes, got the site back
[16:05:25] <wm-bb>	 <IVeertje> tnx
[16:05:36] <dcaro>	 !log tools clearing images from tools-imagebuilder-2 as it's out of space
[16:05:39] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL
[16:28:31] <wm-bot>	 !log lucaswerkmeister@tools-bastion-13 tools.wd-image-positions deployed 8ff73093a1 (l10n updates: uk)
[16:28:33] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.wd-image-positions/SAL
[16:39:58] <dcaro>	 !log tools pushed new ci image docker-registry.svc.toolforge.org/cloud-cicd-py3.11-bookworm-tox:latest
[16:40:01] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL