Steps to reproduce
-
Install Tables 2.2.2 on Nextcloud 33 with PostgreSQL.
-
Inspect the indexes on oc_tables_row_sleeves:
SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'oc_tables_row_sleeves'
ORDER BY indexname;
-
Observe that an index on table_id already exists:
tables_tables_row_sleeves_t_id
CREATE INDEX tables_tables_row_sleeves_t_id
ON public.oc_tables_row_sleeves USING btree (table_id)
-
Run:
php occ db:add-missing-indices --dry-run
-
Observe that Nextcloud proposes another index on the same column:
Adding additional tables_row_sleeves_t_id index to the
oc_tables_row_sleeves table, this can take some time...
CREATE INDEX tables_row_sleeves_t_id
ON oc_tables_row_sleeves (table_id);
Expected behavior
db:add-missing-indices should not propose a second index when an equivalent index on tables_row_sleeves(table_id) already exists.
The Tables schema migration and AddMissingIndicesListener should use a consistent index name. Existing installations using the migration-defined name should be handled without creating a duplicate index.
Actual behavior
The original Tables migration creates tables_tables_row_sleeves_t_id, while the current AddMissingIndicesListener registers tables_row_sleeves_t_id.
Nextcloud checks the registered index by name, treats the migration-created index as missing, and proposes a second B-tree index on the same table_id column. Running the command without --dry-run would create both indexes instead of recognizing or replacing the existing one.
Tables app version
2.2.2
Browser
Not applicable (server-side OCC/schema issue)
Client operating system
Not applicable
Operating system
Alpine Linux 3.24.1 container on Kubernetes
Web server
Nginx
PHP engine version
PHP 8.3
Database
PostgreSQL
Additional info
Nextcloud version: 33.0.8 Enterprise
PHP-FPM: 8.3.33
Nginx: 1.31.3
PostgreSQL: 18.4
Relevant source locations:
The mismatch is also present on the current Tables main branch.
The existing index is functional and actively used by PostgreSQL for queries filtering on table_id, so this is not a missing-index performance problem. The issue is that the maintenance command proposes a redundant index and leaves the database warning active.
A fix should account for installations where only the migration-defined name exists, only the listener-defined name exists, or both names exist because the maintenance command was already executed.
Steps to reproduce
Install Tables 2.2.2 on Nextcloud 33 with PostgreSQL.
Inspect the indexes on
oc_tables_row_sleeves:Observe that an index on
table_idalready exists:Run:
Observe that Nextcloud proposes another index on the same column:
Expected behavior
db:add-missing-indicesshould not propose a second index when an equivalent index ontables_row_sleeves(table_id)already exists.The Tables schema migration and
AddMissingIndicesListenershould use a consistent index name. Existing installations using the migration-defined name should be handled without creating a duplicate index.Actual behavior
The original Tables migration creates
tables_tables_row_sleeves_t_id, while the currentAddMissingIndicesListenerregisterstables_row_sleeves_t_id.Nextcloud checks the registered index by name, treats the migration-created index as missing, and proposes a second B-tree index on the same
table_idcolumn. Running the command without--dry-runwould create both indexes instead of recognizing or replacing the existing one.Tables app version
2.2.2
Browser
Not applicable (server-side OCC/schema issue)
Client operating system
Not applicable
Operating system
Alpine Linux 3.24.1 container on Kubernetes
Web server
Nginx
PHP engine version
PHP 8.3
Database
PostgreSQL
Additional info
Nextcloud version: 33.0.8 Enterprise
PHP-FPM: 8.3.33
Nginx: 1.31.3
PostgreSQL: 18.4
Relevant source locations:
tables_tables_row_sleeves_t_id:https://github.com/nextcloud/tables/blob/v2.2.2/lib/Migration/Version000700Date20230916000000.php#L81-L96
tables_row_sleeves_t_id:https://github.com/nextcloud/tables/blob/v2.2.2/lib/Listener/AddMissingIndicesListener.php#L15-L23
https://github.com/nextcloud/server/blob/v33.0.8/core/Command/Db/AddMissingIndices.php#L50-L73
The mismatch is also present on the current Tables
mainbranch.The existing index is functional and actively used by PostgreSQL for queries filtering on
table_id, so this is not a missing-index performance problem. The issue is that the maintenance command proposes a redundant index and leaves the database warning active.A fix should account for installations where only the migration-defined name exists, only the listener-defined name exists, or both names exist because the maintenance command was already executed.