Duplicate entries in pg_depend after REINDEX CONCURRENTLY

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Duplicate entries in pg_depend after REINDEX CONCURRENTLY
Date: 2019-10-25 06:43:18
Message-ID: 20191025064318.GF8671@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi all,

While digging into a separate issue, I have found a new bug with
REINDEX CONCURRENTLY. Once the new index is built and validated,
a couple of things are done at the swap phase, like switching
constraints, comments, and dependencies. The current code moves all
the dependency entries of pg_depend from the old index to the new
index, but it never counted on the fact that the new index may have
some entries already. So, once the swapping is done, pg_depend
finishes with duplicated entries: the ones coming from the old index
and the ones of the index freshly-created. For example, take an index
which uses an attribute or an expression and has dependencies with the
parent's columns.

Attached is a patch to fix the issue. As we know that the old index
will have a definition and dependencies that match with the old one, I
think that we should just remove any dependency records on the new
index before moving the new set of dependencies from the old to the
new index. The patch includes regression tests that scan pg_depend to
check that everything remains consistent after REINDEX CONCURRENTLY.

Any thoughts?

Attachment Content-Type Size
reindex-conc-deps.patch text/x-diff 14.5 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2019-10-25 06:54:53 Re: Fix of fake unlogged LSN initialization
Previous Message Virender Singla 2019-10-25 06:03:11 vacuum on table1 skips rows because of a query on table2