Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

syscache.c

Blame
    • Tom Lane's avatar
      9a75803b
      Remove CatalogCacheFlushRelation, and the reloidattr infrastructure that was · 9a75803b
      Tom Lane authored
      needed by nothing else.
      
      The restructuring I just finished doing on cache management exposed to me how
      silly this routine was.  Its function was to go into the catcache and blow
      away all entries related to a given relation when there was a relcache flush
      on that relation.  However, there is no point in removing a catcache entry
      if the catalog row it represents is still valid --- and if it isn't valid,
      there must have been a catcache entry flush on it, because that's triggered
      directly by heap_update or heap_delete on the catalog row.  So this routine
      accomplished nothing except to blow away valid cache entries that we'd very
      likely be wanting in the near future to help reconstruct the relcache entry.
      Dumb.
      
      On top of which, it required a subtle and easy-to-get-wrong attribute in
      syscache definitions, ie, the column containing the OID of the related
      relation if any.  Removing that is a very useful maintenance simplification.
      9a75803b
      History
      Remove CatalogCacheFlushRelation, and the reloidattr infrastructure that was
      Tom Lane authored
      needed by nothing else.
      
      The restructuring I just finished doing on cache management exposed to me how
      silly this routine was.  Its function was to go into the catcache and blow
      away all entries related to a given relation when there was a relcache flush
      on that relation.  However, there is no point in removing a catcache entry
      if the catalog row it represents is still valid --- and if it isn't valid,
      there must have been a catcache entry flush on it, because that's triggered
      directly by heap_update or heap_delete on the catalog row.  So this routine
      accomplished nothing except to blow away valid cache entries that we'd very
      likely be wanting in the near future to help reconstruct the relcache entry.
      Dumb.
      
      On top of which, it required a subtle and easy-to-get-wrong attribute in
      syscache definitions, ie, the column containing the OID of the related
      relation if any.  Removing that is a very useful maintenance simplification.