postgres.git / summary / log / commit / refs

commit    fbcf0871123b464fef7f957301dcc57377cde9c5
Author:   Michael Paquier <michael@paquier.xyz>
Date:     Thu Mar 05 03:50:15 2020 +0000
First released in: 13.0, 12.3

    Fix more issues with dependency handling at swap phase of REINDEX CONCURRENTLY
    
    When canceling a REINDEX CONCURRENTLY operation after swapping is done,
    a drop of the parent table would leave behind old indexes.  This is a
    consequence of 68ac9cf, which fixed the case of pg_depend bloat when
    repeating REINDEX CONCURRENTLY on the same relation.
    
    In order to take care of the problem without breaking the previous fix,
    this uses a different strategy, possible even with the exiting set of
    routines to handle dependency changes.  The dependencies of/on the
    new index are additionally switched to the old one, allowing an old
    invalid index remaining around because of a cancellation or a failure to
    use the dependency links of the concurrently-created index.  This
    ensures that dropping any objects the old invalid index depends on also
    drops the old index automatically.
    
    Reported-by: Julien Rouhaud
    Author: Michael Paquier
    Reviewed-by: Julien Rouhaud
    Discussion: https://postgr.es/m/20200227080735.l32fqcauy73lon7o@nol
    Backpatch-through: 12


 src/backend/catalog/index.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 1681f61727e..72236790338 100644
--- a/src/backend/catalog/index.c
+++ b/src/backend/catalog/index.c
@@ -1675,12 +1675,13 @@ index_concurrently_swap(Oid newIndexId, Oid oldIndexId, const char *oldName)
 	}
 
 	/*
-	 * Move all dependencies of and on the old index to the new one.  First
-	 * remove any dependencies that the new index may have to provide an
-	 * initial clean state for the dependency switch, and then move all the
-	 * dependencies from the old index to the new one.
+	 * Swap all dependencies of and on the old index to the new one, and
+	 * vice-versa.  Note that a call to CommandCounterIncrement() would cause
+	 * duplicate entries in pg_depend, so this should not be done.
 	 */
-	deleteDependencyRecordsFor(RelationRelationId, newIndexId, false);
+	changeDependenciesOf(RelationRelationId, newIndexId, oldIndexId);
+	changeDependenciesOn(RelationRelationId, newIndexId, oldIndexId);
+
 	changeDependenciesOf(RelationRelationId, oldIndexId, newIndexId);
 	changeDependenciesOn(RelationRelationId, oldIndexId, newIndexId);
 


[parent: c954d4904650]