Skip to content

db:add-missing-indices proposes duplicate table_id index for tables_row_sleeves #2922

Description

@rezss

Steps to reproduce

  1. Install Tables 2.2.2 on Nextcloud 33 with PostgreSQL.

  2. Inspect the indexes on oc_tables_row_sleeves:

    SELECT indexname, indexdef
    FROM pg_indexes
    WHERE tablename = 'oc_tables_row_sleeves'
    ORDER BY indexname;
  3. 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)
    
  4. Run:

    php occ db:add-missing-indices --dry-run
  5. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    0. Needs triagePending approval or rejection. This issue is pending approval.bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions