Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit c1500a1

Browse files
committed
Update header comment for lookup_type_cache()
Describe the way we handle concurrent invalidation messages. Discussion: https://postgr.es/m/CAPpHfdsQhwUrnB3of862j9RgHoJM--eRbifvBMvtQxpC57dxCA%40mail.gmail.com Reviewed-by: Andrei Lepikhov, Artur Zakirov, Pavel Borisov
1 parent 499edb0 commit c1500a1

File tree

1 file changed

+9
-0
lines changed

1 file changed

+9
-0
lines changed

src/backend/utils/cache/typcache.c

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -351,6 +351,15 @@ type_cache_syshash(const void *key, Size keysize)
351351
* invalid. Note however that we may fail to find one or more of the
352352
* values requested by 'flags'; the caller needs to check whether the fields
353353
* are InvalidOid or not.
354+
*
355+
* Note that while filling TypeCacheEntry we might process concurrent
356+
* invalidation messages, causing our not-yet-filled TypeCacheEntry to be
357+
* invalidated. In this case, we typically only clear flags while values are
358+
* still available for the caller. It's expected that the caller holds
359+
* enough locks on type-depending objects that the values are still relevant.
360+
* It's also important that the tupdesc is filled after all other
361+
* TypeCacheEntry items for TYPTYPE_COMPOSITE. So, tupdesc can't get
362+
* invalidated during the lookup_type_cache() call.
354363
*/
355364
TypeCacheEntry *
356365
lookup_type_cache(Oid type_id, int flags)

0 commit comments

Comments
 (0)