I want to add some information. The error occurred while upgrading using the web interface.
Today, we tried to test the upgrade again with a fresh database on version 1.39.4 again, but now using the run.php update command and the error we encountered is the same described in https://phabricator.wikimedia.org/T374042. I dont know if the error "index "pl_namespace" does not exist" will appears using run.php update command. I will apply the fix described in https://phabricator.wikimedia.org/T374042 and see if the issue of this task will repeat.

Adding another info, I dont think this task have something to do with T330382. I missread pl_namespace with tl_namespace.
Is this error will be fixed if you add if exist in the patch-pagelinks-drop-pl_title.sql code? This was the solution for T330382.

Executing the patch_pagelinks_drop_pl_title.sql manually, I found the following outputs:

wiki_143_hml=# DROP INDEX pl_namespace;
DROP INDEX pl_backlinks_namespace;
ALTER TABLE pagelinks
  DROP CONSTRAINT pagelinks_pkey;
ALTER TABLE pagelinks
  DROP pl_namespace;
ALTER TABLE pagelinks
  DROP pl_title;
ALTER TABLE pagelinks
  ALTER pl_target_id
SET
  NOT NULL;
ALTER TABLE pagelinks
  ADD PRIMARY KEY (pl_from, pl_target_id);
ERROR:  index "pl_namespace" does not exist
ERROR:  index "pl_backlinks_namespace" does not exist
ERROR:  constraint "pagelinks_pkey" of relation "pagelinks" does not exist
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE

Observation: The site_group index error occours only the first time it is executed. The second time it wont happen.

I'm not sure this is related to T330382 ... after all I seem to have reported that problem...

I just upgraded 56 Wikis from 1.39.12 to 1.43.3. Of those 27 failed with the error described above. My workaround was to recreate the missing things in their respective databases and let the installer remove it afterwards:

CREATE INDEX pl_namespace ON pagelinks (pl_namespace, pl_title, pl_from);
CREATE INDEX pl_backlinks_namespace ON pagelinks (pl_from_namespace, pl_namespace, pl_title, pl_from);
ALTER TABLE pagelinks ADD CONSTRAINT pagelinks_pkey PRIMARY KEY (pl_from, pl_namespace, pl_title);

The affected Wikis were initially created with 1.35 or 1.31, maybe even 1.27 and updated from time to time to the then current LTS release. The unaffected remaining 29 Wikis were created early 2023 or later, probably when I had upgraded to 1.39, so they didn't carry any baggage from those older releases.

This is again all with PostgreSQL as database.

Hello joernc_unibi ,

First of all, thank you for replying my post. I misread the index name and thought it was a related error to the https://phabricator.wikimedia.org/T330382. I made exactaly what you said, I recreated the index and let the installation drop. I made this, because the SQL scripts from mysql checks if the index exists and the postgreSQL scripts does not. Let me ask you, do you think it is better use media wiki with mysql (mariaDB) than use it with PostgreSQL?

Please see https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#Set_up_the_database instead - thanks.

Do you still have backups of the old databases and can check if those indices existed at all in the old MediaWiki versions?

The updater tries to drop them because it has a generic database agnostic rule to drop them, but maybe they were never created for Postgres in the first place?

@saper Sorry, I don't have backups from the time before I upgraded all Wikis to 1.39, that was 2023. At the moment my test environment has only the latest version and I am upgrading my test Wikis before the productive ones. I am considering installing the old releases in my test environment so that I can actually test these upgrade chains. If e.g. these older releases are compatible with a recent PostgreSQL database, though.

@Leduardomoreira I can't tell, I've always used PostgreSQL for the Wikis. In my totally personal and biased opinion, I prefer PGSQL over MySQL, because the rights and access management of the latter drives me crazy and I like the inline help system of the first. I've been using PGSQL from time to time over the last 25+ years, and I always had the impression that it was much closer to enterprise solutions like Oracle. But to quote from the page @Aklapper mentioned:

MariaDB/MySQL are the recommended databases. While PostgreSQL and SQLite are supported, they offer limited compatibility and should only be used only if necessary. If you're unsure which database to choose, use MariaDB.

I don't know if the two "onlies" are a deliberate choice or just a fluke :) ...

On the other hand: Whenever I had problems related to the database, I found help here in this forum and some kind developer usually would fix the code.

@joernc_unibi I asked the developers about the database choice, because I read that line you quoted. I wanted their opinion if it worths migrating from PG to MariaDB since we have these problems with postgresql DB scripts.
I will study a possible migration to MariaDB, because it is time consuming try to fix things that are only broken on PG scripts. It is tiny problems like droping a collumn or an index that should exists and brokes the upgrade sequence. Even though it is tiny problems, we (the final user) dont have the impact of bypassing these drops.

I prefer Postgres too. I dont like de management of MariaDB/MySQL either.