@@ -1858,8 +1858,8 @@ index_update_stats(Relation rel,
18581858 * 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work.
18591859 *
18601860 * 2. We could be reindexing pg_class itself, in which case we can't move
1861- * its pg_class row becauseCatalogUpdateIndexes might not know about all
1862- * the indexes yet (see reindex_relation).
1861+ * its pg_class row becauseCatalogTupleInsert/CatalogTupleUpdate might
1862+ *not know about all the indexes yet (see reindex_relation).
18631863 *
18641864 * 3. Because we execute CREATE INDEX with just share lock on the parent
18651865 * rel (to allow concurrent index creations), an ordinary update could
@@ -3542,9 +3542,9 @@ reindex_relation(Oid relid, int flags, int options)
35423542 * that the updates do not try to insert index entries into indexes we
35433543 * have not processed yet. (When we are trying to recover from corrupted
35443544 * indexes, that could easily cause a crash.) We can accomplish this
3545- * becauseCatalogUpdateIndexes will use the relcache's index list to know
3546- * which indexes to update. We just force the index list to be only the
3547- * stuff we've processed.
3545+ * becauseCatalogTupleInsert/CatalogTupleUpdate will use the relcache's
3546+ *index list to know which indexes to update. We just force the index
3547+ *list to be only the stuff we've processed.
35483548 *
35493549 * It is okay to not insert entries into the indexes we have not processed
35503550 * yet because all of this is transaction-safe. If we fail partway