|
51 | 51 | *PrepareToInvalidateCacheTuple() routine provides the knowledge of which |
52 | 52 | *catcaches may need invalidation for a given tuple. |
53 | 53 | * |
54 | | - *Also, whenever we see an operation on a pg_class orpg_attribute tuple, |
55 | | - *we register a relcache flush operation for the relation described by that |
56 | | - *tuple. |
| 54 | + *Also, whenever we see an operation on a pg_class,pg_attribute, or |
| 55 | + *pg_index tuple,we register a relcache flush operation for the relation |
| 56 | + *described by thattuple (as specified in CacheInvalidateHeapTuple()). |
57 | 57 | * |
58 | 58 | *We keep the relcache flush requests in lists separate from the catcache |
59 | 59 | *tuple flush requests. This allows us to issue all the pending catcache |
@@ -1132,6 +1132,7 @@ CacheInvalidateHeapTuple(Relation relation, |
1132 | 1132 |
|
1133 | 1133 | /* |
1134 | 1134 | * Now, is this tuple one of the primary definers of a relcache entry? |
| 1135 | + * See comments in file header for deeper explanation. |
1135 | 1136 | * |
1136 | 1137 | * Note we ignore newtuple here; we assume an update cannot move a tuple |
1137 | 1138 | * from being part of one relcache entry to being part of another. |
|