fix: PostgreSQL transaction aborts when caching user mounts

[AIlkiv]

• Resolves: [Bug]: Update failes to 32.0.4 / "mounts_user_root_path_index" does not exist on table "oc_mounts" #57572

Summary

On PostgreSQL, the current implementation of UserMountCache::registerMounts() / addToCache() is not transaction‑safe. When a duplicate entry hits the unique index on mounts, the code catches the unique-constraint exception but the surrounding transaction on PostgreSQL remains in the aborted state. All subsequent statements in that transaction then fail with SQLSTATE[25P02]: current transaction is aborted, commands ignored until end of transaction block when mounts are registered.

Why this matters:

1. Not PostgreSQL-compatible: Silently swallowing the unique-constraint exception works on MySQL/SQLite, but breaks transaction semantics on PostgreSQL.
2. Potentially fixes [Bug]: Update failes to 32.0.4 / "mounts_user_root_path_index" does not exist on table "oc_mounts" #57572, which is related to the new mount_point_hash / mounts_user_root_path_index migration and mount cache.
3. Cleaner solution: Using IDBConnection::insertIgnoreConflict('mounts', [...]) (which maps to INSERT ... ON CONFLICT DO NOTHING on PostgreSQL) is more idiomatic, avoids exceptions entirely, and keeps the transaction valid across all supported databases.

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[provokateurin]

The problem might exist, but this code change doesn't fix it. See

server/lib/private/DB/Adapter.php

Lines 114 to 128 in fe612bb

	public function insertIgnoreConflict(string $table, array $values) : int {
	try {
	$builder = $this->conn->getQueryBuilder();
	$builder->insert($table);
	foreach ($values as $key => $value) {
	$builder->setValue($key, $builder->createNamedParameter($value));
	}
	return $builder->executeStatement();
	} catch (DbalException $e) {
	if ($e->getReason() === \OCP\DB\Exception::REASON_UNIQUE_CONSTRAINT_VIOLATION) {
	return 0;
	}
	throw $e;
	}
	}

, it does exactly the same as the existing code.

[AIlkiv]

The problem might exist, but this code change doesn't fix it. See

server/lib/private/DB/Adapter.php

Lines 114 to 128 in fe612bb

	public function insertIgnoreConflict(string $table, array $values) : int {
	try {
	$builder = $this->conn->getQueryBuilder();
	$builder->insert($table);
	foreach ($values as $key => $value) {
	$builder->setValue($key, $builder->createNamedParameter($value));
	}
	return $builder->executeStatement();
	} catch (DbalException $e) {
	if ($e->getReason() === \OCP\DB\Exception::REASON_UNIQUE_CONSTRAINT_VIOLATION) {
	return 0;
	}
	throw $e;
	}
	}

, it does exactly the same as the existing code.

@provokateurin This problem arises specifically for PostgreSQL.
Therefore, you need to look in AdapterPgSql.

server/lib/private/DB/AdapterPgSql.php

Lines 26 to 36 in fe612bb

	public function insertIgnoreConflict(string $table, array $values) : int {
	// "upsert" is only available since PgSQL 9.5, but the generic way
	// would leave error logs in the DB.
	$builder = $this->conn->getQueryBuilder();
	$builder->insert($table);
	foreach ($values as $key => $value) {
	$builder->setValue($key, $builder->createNamedParameter($value));
	}
	$queryString = $builder->getSQL() . ' ON CONFLICT DO NOTHING';
	return $this->conn->executeUpdate($queryString, $builder->getParameters(), $builder->getParameterTypes());
	}