database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-11 10:01:57 +03:00
Code Activity

Update comments overlooked by 2f5c9d9c9c.

Browse Source 
Tomas Vondra
This commit is contained in:
Robert Haas
2017-03-02 17:03:50 +05:30
parent 7f3112135e
commit fa42b2005f
2 changed files with 7 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/catalog/index.c
View File

@ -1858,8 +1858,8 @@ index_update_stats(Relation rel,
* 1. In bootstrap mode, we have no choice --- UPDATE wouldn't work. * 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 * 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 * its pg_class row because CatalogTupleInsert/CatalogTupleUpdate might
* the indexes yet (see reindex_relation). * not know about all the indexes yet (see reindex_relation).
* *
* 3. Because we execute CREATE INDEX with just share lock on the parent * 3. Because we execute CREATE INDEX with just share lock on the parent
* rel (to allow concurrent index creations), an ordinary update could * 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 * 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 * have not processed yet. (When we are trying to recover from corrupted
* indexes, that could easily cause a crash.) We can accomplish this * indexes, that could easily cause a crash.) We can accomplish this
* because CatalogUpdateIndexes will use the relcache's index list to know * because CatalogTupleInsert/CatalogTupleUpdate will use the relcache's
* which indexes to update. We just force the index list to be only the * index list to know which indexes to update. We just force the index
* stuff we've processed. * list to be only the stuff we've processed.
* *
* It is okay to not insert entries into the indexes we have not 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 * yet because all of this is transaction-safe. If we fail partway

6
src/backend/utils/cache/syscache.c vendored
View File

@ -100,10 +100,8 @@
adding/deleting caches only requires a recompile.) adding/deleting caches only requires a recompile.)
Finally, any place your relation gets heap_insert() or Finally, any place your relation gets heap_insert() or
heap_update() calls, make sure there is a CatalogUpdateIndexes() or heap_update() calls, use CatalogTupleInsert() or CatalogTupleUpdate()
similar call. The heap_* calls do not update indexes. instead, which also update indexes. The heap_* calls do not do that.
bjm 1999/11/22
*--------------------------------------------------------------------------- *---------------------------------------------------------------------------
*/ */