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 |
Thread: | |
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?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
reindex-conc-deps.patch | text/x-diff | 14.5 KB |
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 |