Update comments overlooked by 2f5c9d9c9cec436e55847ec580606d7e88067df6.
authorRobert Haas <rhaas@postgresql.org>
Thu, 2 Mar 2017 11:33:50 +0000 (17:03 +0530)
committerRobert Haas <rhaas@postgresql.org>
Thu, 2 Mar 2017 11:33:50 +0000 (17:03 +0530)
Tomas Vondra

src/backend/catalog/index.c
src/backend/utils/cache/syscache.c

index f8d92145e86f41c7e1bf4f8fb94158e47ec70921..8d42a347ea555b50e6c234b2c5b9eb65e217ebf4 100644 (file)
@@ -1858,8 +1858,8 @@ index_update_stats(Relation rel,
     * 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work.
     *
     * 2. We could be reindexing pg_class itself, in which case we can't move
-    * its pg_class row because CatalogUpdateIndexes might not know about all
-    * the indexes yet (see reindex_relation).
+    * its pg_class row because CatalogTupleInsert/CatalogTupleUpdate might
+    * not know about all the indexes yet (see reindex_relation).
     *
     * 3. Because we execute CREATE INDEX with just share lock on the parent
     * rel (to allow concurrent index creations), an ordinary update could
@@ -3542,9 +3542,9 @@ reindex_relation(Oid relid, int flags, int options)
     * that the updates do not try to insert index entries into indexes we
     * have not processed yet.  (When we are trying to recover from corrupted
     * indexes, that could easily cause a crash.) We can accomplish this
-    * because CatalogUpdateIndexes will use the relcache's index list to know
-    * which indexes to update. We just force the index list to be only the
-    * stuff we've processed.
+    * because CatalogTupleInsert/CatalogTupleUpdate will use the relcache's
+    * index list to know which indexes to update. We just force the index
+    * list to be only the stuff we've processed.
     *
     * It is okay to not insert entries into the indexes we have not processed
     * yet because all of this is transaction-safe.  If we fail partway
index bdfaa0ce758401186f05cb79bf929f30e78f1d86..b1c0b4b1be11d0d915f5e9a9342400542368bc0e 100644 (file)
    adding/deleting caches only requires a recompile.)
 
    Finally, any place your relation gets heap_insert() or
-   heap_update() calls, make sure there is a CatalogUpdateIndexes() or
-   similar call.  The heap_* calls do not update indexes.
-
-   bjm 1999/11/22
+   heap_update() calls, use CatalogTupleInsert() or CatalogTupleUpdate()
+   instead, which also update indexes.  The heap_* calls do not do that.
 
 *---------------------------------------------------------------------------
 */