Something unhealthy is going on, I grabbed a similar query from server logs:

gis=> explain analyse SELECT id, ST_Multi(ST_Union(way)) AS way
        FROM (
          SELECT tags->'wikidata' AS id, (ST_Dump(way)).geom AS way
          FROM "planet_osm_line"
          WHERE tags ? 'wikidata' AND tags->'wikidata' IN ('Q12130')
          ) combq
        GROUP BY id;

 HashAggregate  (cost=50959.93..50975.43 rows=200 width=64) (actual time=86060.888..86060.890 rows=1 loops=1)
   Group Key: (planet_osm_line.tags -> 'wikidata'::text)
   ->  Index Scan using planet_osm_line_wikidata on planet_osm_line  (cost=0.43..16914.93 rows=619000 width=304) (actual time=0.198..95.472 rows=888 loops=1)
         Index Cond: ((tags -> 'wikidata'::text) = 'Q12130'::text)
 Planning time: 0.235 ms
 Execution time: 86083.500 ms

This mysteriously omits what the hell most of query execution time gets spent on.

https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q12130 reports "canceling statement due to statement timeout"

So that's consistent with a slow query. Looking at the explain analyze, the time spent on the aggregate for the group by, and in this case, I know its in ST_Union.

The inner select is returning 888 linestrings with 263k vertexes which ST_Union has to process and attempt to merge.

Depending on what the expected result of this query is, perhaps it should be using ST_Collect, not ST_Union.

Maybe you could at least ignore the layer in JavaScript if there’s errors for loading it? Right now it bugs out the whole map, and that’s not the best behaviour even if there’s more underlying problems.

In T162554#3175429, @stjn wrote:

Maybe you could at least ignore the layer in JavaScript if there’s errors for loading it? Right now it bugs out the whole map, and that’s not the best behaviour even if there’s more underlying problems.

There is a ticket for gracefully handling invalid data layers, see T148883. Please join the discussion.

On this ticket, I suggest we focus on this specific bug.

Based on the conversation in T162554, removing the sprint tag as we won't be working on this anytime soon.