Why:
- From MediaWiki 1.36 to MediaWiki 1.44 (inclusive),
`PostgresUpdater.php` contains a typo in the instruction to rename
the `sites_group` index to `site_group`.
- This typo means that - on Postgres wikis - the MediaWiki update
script will not currently rename this index as intended, as the index
which the updater is told to rename (i.e., containing the typo)
doesn't exist.
- From MediaWiki 1.42 onwards, this typo indirectly causes `update.php`
on Postgres wikis to throw an error on its first run:
- From MW 1.42 onwards, the update script included an instruction to
drop multiple indexes on the `sites` table, including this index
that was previously intended to be renamed.
- However, as this typo meant that the `sites_group` index was never
renamed on Postgres wikis, the database is unable to find the
renamed index in order to drop it; and consequently throws an
error (reported on Phabricator as T374042).
- This only affects the first run of `update.php` due to the fact
that - when deciding whether to apply the patch containing _all_ of
the index-drops for the `sites` table - the `dropIndex` instruction
only checks for the existence of the `site_type` index (and, if the
`site_type` index doesn't exist, the patch as a whole isn't applied).
However, as - within `patch-sites-drop_indexes.sql` - the statement
to drop the `site_type` index is located _before_ the instruction to
drop the `site_group` index, the `site_type` index will have been
dropped on the first run of `update.php`.
- This also means that - on any future runs of `update.php` - the
indexes listed after (and including) `site_group` in that SQL file
will currently remain un-dropped.
What:
- Fix the typo in the PostgresUpdater index renaming instruction:
`'sites_group, '` -> `'sites_group'`
- Update PostgresUpdater to individually re-attempt to drop the indexes
listed after & including `site_group` in
`patch-sites-drop_indexes.sql`, to ensure that they're dropped on
Postgres wikis that have already (1) upgraded to MW 1.42+, & (2) ran
`update.php`.
(These could theoretically have all been combined within one extra
SQL patch, rather than one for each index; but I thought it might be
best for the updater to check for the existence of each of these
indexes individually before it attempts to drop each one.)
Follows-up 9907b56c9b, 616744db1d
Bug: T374042
Change-Id: Ie6ffa92153e64ca653f726a35a5a6b5d95d093f5
ffa868bcf1