]> granicus.if.org Git - postgresql/commitdiff
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.
 
 *---------------------------------------------------------------------------
 */