Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit fbcf087

Browse files
committed
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
1 parent c954d49 commit fbcf087

File tree

1 file changed

+6
-5
lines changed

1 file changed

+6
-5
lines changed

src/backend/catalog/index.c

+6-5
Original file line numberDiff line numberDiff line change
@@ -1675,12 +1675,13 @@ index_concurrently_swap(Oid newIndexId, Oid oldIndexId, const char *oldName)
16751675
}
16761676

16771677
/*
1678-
* Move all dependencies of and on the old index to the new one. First
1679-
* remove any dependencies that the new index may have to provide an
1680-
* initial clean state for the dependency switch, and then move all the
1681-
* dependencies from the old index to the new one.
1678+
* Swap all dependencies of and on the old index to the new one, and
1679+
* vice-versa. Note that a call to CommandCounterIncrement() would cause
1680+
* duplicate entries in pg_depend, so this should not be done.
16821681
*/
1683-
deleteDependencyRecordsFor(RelationRelationId, newIndexId, false);
1682+
changeDependenciesOf(RelationRelationId, newIndexId, oldIndexId);
1683+
changeDependenciesOn(RelationRelationId, newIndexId, oldIndexId);
1684+
16841685
changeDependenciesOf(RelationRelationId, oldIndexId, newIndexId);
16851686
changeDependenciesOn(RelationRelationId, oldIndexId, newIndexId);
16861687

0 commit comments

Comments
 (0)