Don't run RelationInitTableAccessMethod in a long-lived context.

Some code paths in this function perform syscache lookups, which
can lead to table accesses and possibly leakage of cruft into
the caller's context.  If said context is CacheMemoryContext,
we eventually will have visible bloat.  But fixing this is no
harder than moving one memory context switch step.  (The other
callers don't have a problem.)

Andres Freund and I independently found this via valgrind testing.
Back-patch to v12 where this code was added.

Discussion: https://postgr.es/m/20210317023101.anvejcfotwka6gaa@alap3.anarazel.de
Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us

diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index b0e06c037f440b275daf62fbe368f8a7cba51349..20be094f460ebad7298893b0d38d7f5e93945dc0 100644 (file)
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -3543,6 +3543,13 @@ RelationBuildLocalRelation(const char *relname,
 
    rel->rd_rel->relam = accessmtd;
 
+   /*
+    * RelationInitTableAccessMethod will do syscache lookups, so we mustn't
+    * run it in CacheMemoryContext.  Fortunately, the remaining steps don't
+    * require a long-lived current context.
+    */
+   MemoryContextSwitchTo(oldcxt);
+
    if (relkind == RELKIND_RELATION ||
        relkind == RELKIND_SEQUENCE ||
        relkind == RELKIND_TOASTVALUE ||
@@ -3566,11 +3573,6 @@ RelationBuildLocalRelation(const char *relname,
     */
    EOXactListAdd(rel);
 
-   /*
-    * done building relcache entry.
-    */
-   MemoryContextSwitchTo(oldcxt);
-
    /* It's fully valid */
    rel->rd_isvalid = true;