[HACKERS] Rethinking autovacuum.c memory handling

I notice that autovacuum.c calls autovacuum_do_vac_analyze, and
thereby vacuum(), in TopTransactionContext.  This doesn't seem
like a terribly great idea, because it doesn't correspond to what
happens during a manually-invoked vacuum.  TopTransactionContext
will go away when vacuum() commits the outer transaction, whereas
in non-autovac usage, we call vacuum() in a PortalHeapMemory
context that is not a child of TopTransactionContext and is not
at risk of being reset multiple times during the vacuum().  This'd
be a hazard if autovacuum_do_vac_analyze or vacuum did any palloc's
before getting to the main loop.  More generally, I'm not aware of
other cases where we invoke a function in a context that we know
that function will destroy as it executes.

I don't see any live bug associated with this in HEAD, but this behavior
requires a rather ugly (and memory-leaking) workaround in the proposed
patch to allow multiple vacuum target rels.

What I think we should do instead is invoke autovacuum_do_vac_analyze
in the PortalContext that do_autovacuum has created, which we already
have a mechanism to reset once per table processed in do_autovacuum.

The attached patch does that, and also modifies perform_work_item()
to use the same approach.  Right now perform_work_item() has a
copied-and-pasted MemoryContextResetAndDeleteChildren(PortalContext)
call in its error recovery path, but that seems a bit out of place
given that perform_work_item() isn't using PortalContext otherwise.

Comments, objections?

            regards, tom lane

PS: I was disappointed to find out that perform_work_item() isn't
exercised at all in the standard regression tests.

diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index b745d89..1a32433 100644
*** a/src/backend/postmaster/autovacuum.c
--- b/src/backend/postmaster/autovacuum.c
*************** do_autovacuum(void)
*** 2444,2451 ****
           */
          PG_TRY();
          {
              /* have at it */
-             MemoryContextSwitchTo(TopTransactionContext);
              autovacuum_do_vac_analyze(tab, bstrategy);

              /*
--- 2444,2453 ----
           */
          PG_TRY();
          {
+             /* Use PortalContext for any per-table allocations */
+             MemoryContextSwitchTo(PortalContext);
+
              /* have at it */
              autovacuum_do_vac_analyze(tab, bstrategy);

              /*
*************** do_autovacuum(void)
*** 2482,2487 ****
--- 2484,2492 ----
          }
          PG_END_TRY();

+         /* Make sure we're back in AutovacMemCxt */
+         MemoryContextSwitchTo(AutovacMemCxt);
+
          did_vacuum = true;

          /* the PGXACT flags are reset at the next end of transaction */
*************** perform_work_item(AutoVacuumWorkItem *wo
*** 2614,2619 ****
--- 2619,2627 ----

      autovac_report_workitem(workitem, cur_nspname, cur_datname);

+     /* clean up memory before each work item */
+     MemoryContextResetAndDeleteChildren(PortalContext);
+
      /*
       * We will abort the current work item if something errors out, and
       * continue with the next one; in particular, this happens if we are
*************** perform_work_item(AutoVacuumWorkItem *wo
*** 2622,2630 ****
       */
      PG_TRY();
      {
!         /* have at it */
!         MemoryContextSwitchTo(TopTransactionContext);

          switch (workitem->avw_type)
          {
              case AVW_BRINSummarizeRange:
--- 2630,2639 ----
       */
      PG_TRY();
      {
!         /* Use PortalContext for any per-work-item allocations */
!         MemoryContextSwitchTo(PortalContext);

+         /* have at it */
          switch (workitem->avw_type)
          {
              case AVW_BRINSummarizeRange:
*************** perform_work_item(AutoVacuumWorkItem *wo
*** 2668,2673 ****
--- 2677,2685 ----
      }
      PG_END_TRY();

+     /* Make sure we're back in AutovacMemCxt */
+     MemoryContextSwitchTo(AutovacMemCxt);
+
      /* We intentionally do not set did_vacuum here */

      /* be tidy */

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers