In T411497#11423699, @Marostegui wrote:

$ sudo db-mysql pc1011 parsercache -e "show tables like 'objec%'";
+--------------------------------+
| Tables_in_parsercache (objec%) |
+--------------------------------+
| objectcache                    |
+--------------------------------+

That table probably should be dropped altogether I think. I sorta meant since pc tables (pc101 for example) is created from the objectcache schema, it also might have these two columns)

Yeah they aren't written since 2022 from what I can see

@Ladsgroup I am confused, the patch you linked talks about objectcache table but ms sections do not have that, they have objectstash instead (which does have modtoken), I guess it is a name error?

So the tables are built from the structure of objectcache table. They take the schema of objectcache and use it template to create other tables (see SqlBagOStuff:createTables) and SqlBagOStuff is flexible in terms of the name of the table it needs to query. i.e. the objectcache table schema in core is a template many parts of core use to create tables with other names (including Parser cache tables, main stash tables, etc.)

On ParserCache hosts we instantiate the objectcache template 256 times as pcXXX, like pc128 (wmf-config).

On MainStash hosts we instantiate the template once, like objectstash (wmf-config).

The name is a free form field. There's no requirement for any particular name. We try to make them unique to ease debugging and ease future relocation. The default name of objectcache is thus discouraged anywhere other than core databases (e.g. enwiki.objectcache, metawiki.objectcache). We don't use that in production, but that's what that name would mean to me if I saw it somewhere in a query or error message.

Thank you both. After @Krinkle's message above, I am not sure whether I can proceed deleting them on parsercache or I should wait until the code is cleaned up?

For the ALTER I will just proceed on msX for now.

In T411497#11426803, @Marostegui wrote:

Thank you both. After @Krinkle's message above, I am not sure whether I can proceed deleting them on parsercache or I should wait until the code is cleaned up?

The code has been cleaned up (i.e. the ALTER has been merged) but note that the column might not exist in pc table (or exists in some but not all clusters) since these two columns were added somewhat recently.

Of course this needs depooling for each alter as the table is around 50G

Depooled pc1011.eqiad.wmnet and pc2011.codfw.wmnet Schema change - marostegui@cumin1003 - T411497

Depooled pc1011.eqiad.wmnet and pc2011.codfw.wmnet Schema change - marostegui@cumin1003 - T411497

Depooled db1152.eqiad.wmnet and db2142.codfw.wmnet Schema change - marostegui@cumin1003 - T411497

Mentioned in SAL (#wikimedia-operations) [2026-01-13T06:50:04Z] <marostegui> Deploy schema change on ms1 T411497

Depooled db1152.eqiad.wmnet and db2142.codfw.wmnet After Schema change - marostegui@cumin1003 - T411497

Depooled db1151.eqiad.wmnet and db2144.codfw.wmnet Schema change - marostegui@cumin1003 - T411497

Mentioned in SAL (#wikimedia-operations) [2026-01-13T07:06:04Z] <marostegui> Deploy schema change on ms2 T411497

Depooled db1151.eqiad.wmnet and db2144.codfw.wmnet After Schema change - marostegui@cumin1003 - T411497

Mentioned in SAL (#wikimedia-operations) [2026-01-13T07:10:31Z] <marostegui> Deploy schema change on ms3 T411497

Depooled db1153.eqiad.wmnet and db2143.codfw.wmnet Schema change - marostegui@cumin1003 - T411497

Depooled db1153.eqiad.wmnet and db2143.codfw.wmnet After Schema change - marostegui@cumin1003 - T411497

Completed depooling of db2196 by marostegui@cumin1003: Schema change

Starting pool of db2196 by marostegui@cumin1003: Schema change

In T411497#11516877, @ops-monitoring-bot wrote:

Starting pool of db2196 by marostegui@cumin1003: Schema change

This can be ignored - it was a mistake when using -t in a different task

Completed pooling of db2196 by marostegui@cumin1003: Schema change