[09:56:16] <Remilia>	 also, with PostgreSQL, the job_cmd index for the job table leads to errors: CREATE INDEX job_cmd ON job ( job_cmd, job_namespace, job_title,   job_params ); — rdbms.ERROR: Error 54000 from JobQueueDB::doBatchPush, ERROR:  index row size 2792 exceeds btree version 4 maximum 2704 for index "job_cmd" DETAIL:  Index row references tuple (0,6) in relation "job". HINT:  Values larger than 1/3 of a buffer page cannot be indexed. Consider a function 
[09:56:17] <Remilia>	 index of an MD5 hash of the value, or use full text indexing. 
[09:56:48] <Remilia>	 job_params can be very long
[09:58:43] <Remilia>	 maybe I should actually file an issue on phabricator for this
[10:12:24] <Vulpix>	 https://www.mediawiki.org/wiki/Manual:Job_table  -- job_sha1: Base 36 SHA1 of the job parameters relevant to detecting duplicates. I don't know why an index should exist including job_params. If it's for deduplication, it should use job_sha1 instead
[13:11:11] <Remilia>	 Vulpix: the schema quote above is from https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/tags/1.43.0/maintenance/postgres/tables-generated.sql
[13:12:35] <Remilia>	 there is a similar index in the SQL file for mariadb
[13:13:15] <Remilia>	 https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/tags/1.43.0/maintenance/tables.json#1425 found it
[13:13:50] <Remilia>	 PostgreSQL TEXT does not have length limits, which might be the reason this happens
[13:55:56] <Remilia>	 oh, it looks like it is possible to index based on a string slice
[13:57:10] <Remilia>	 like so: CREATE INDEX job_cmd ON job ( job_cmd, job_namespace, job_title,  left ( job_params, 128 ) );
[14:01:17] <Remilia>	 azurlane_wiki=> CREATE INDEX job_cmd ON mediawiki.job ( job_cmd, job_namespace, job_title,  left ( job_params, 128 ) ); CREATE INDEX
[14:01:21] <Remilia>	 it worked
[14:47:49] <moonmoon>	 not sure why there would be an index on that column in the first place tbh
[14:48:52] <moonmoon>	 the index isn't unique, so the only thing I can think of is that the inclusion in the index is so it doesn't have to go to the underlying table to fetch that data if the query uses only those 4 columns (and no other columns) from the table, which is a very minor optimization given the job table is usually not all that large
[16:14:51] <Remilia>	 moonmoon: should I report this issue on phabricator? (not right now though because it's on past midnight here)
[16:14:54] <Remilia>	 one*
[16:15:59] <Remilia>	 as it is, with postgres some jobs are not added at all since it bails on INSERT