Re: Lots of memory allocated when reassigning Large Objects - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Lots of memory allocated when reassigning Large Objects
Date
Msg-id 1286664.1638214754@sss.pgh.pa.us
Whole thread Raw
In response to Re: Lots of memory allocated when reassigning Large Objects  (Guillaume Lelarge <guillaume@lelarge.info>)
Responses Re: Lots of memory allocated when reassigning Large Objects
List pgsql-hackers
Guillaume Lelarge <guillaume@lelarge.info> writes:
> I've tried Justin's patch but it didn't help with my memory allocation
> issue. FWIW, I attach the patch I used in v14.

[ looks closer ... ]  Ah, that patch is a bit buggy: it fails to do the
right thing in the cases where the loop does a "continue".  The attached
revision seems to behave properly.

I still see a small leakage, which I think is due to accumulation of
pending sinval messages for the catalog updates.  I'm curious whether
that's big enough to be a problem for Guillaume's use case.  (We've
speculated before about bounding the memory used for pending sinval
in favor of just issuing a cache reset when the list would be too
big.  But nobody's done anything about it, suggesting that people
seldom have a problem in practice.)

>> DROP OWNED BY likely has similar issues.

> Didn't try it, but it wouldn't be a surprise.

I tried just changing the REASSIGN to a DROP in Justin's example,
and immediately hit

ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

thanks to the per-object locks we try to acquire.  So I'm not
sure that the DROP case can reach an interesting amount of
local memory leaked before it runs out of lock-table space.

            regards, tom lane

diff --git a/src/backend/catalog/pg_shdepend.c b/src/backend/catalog/pg_shdepend.c
index 9ea42f805f..d7f0708396 100644
--- a/src/backend/catalog/pg_shdepend.c
+++ b/src/backend/catalog/pg_shdepend.c
@@ -65,6 +65,7 @@
 #include "storage/lmgr.h"
 #include "utils/acl.h"
 #include "utils/fmgroids.h"
+#include "utils/memutils.h"
 #include "utils/syscache.h"

 typedef enum
@@ -1497,6 +1498,7 @@ shdepReassignOwned(List *roleids, Oid newrole)
         while ((tuple = systable_getnext(scan)) != NULL)
         {
             Form_pg_shdepend sdepForm = (Form_pg_shdepend) GETSTRUCT(tuple);
+            MemoryContext cxt, oldcxt;

             /*
              * We only operate on shared objects and objects in the current
@@ -1510,6 +1512,11 @@ shdepReassignOwned(List *roleids, Oid newrole)
             if (sdepForm->deptype != SHARED_DEPENDENCY_OWNER)
                 continue;

+            cxt = AllocSetContextCreate(CurrentMemoryContext,
+                                        "shdepReassignOwned",
+                                        ALLOCSET_DEFAULT_SIZES);
+            oldcxt = MemoryContextSwitchTo(cxt);
+
             /* Issue the appropriate ALTER OWNER call */
             switch (sdepForm->classid)
             {
@@ -1598,6 +1605,10 @@ shdepReassignOwned(List *roleids, Oid newrole)
                     elog(ERROR, "unexpected classid %u", sdepForm->classid);
                     break;
             }
+
+            MemoryContextSwitchTo(oldcxt);
+            MemoryContextDelete(cxt);
+
             /* Make sure the next iteration will see my changes */
             CommandCounterIncrement();
         }

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Non-superuser subscription owners
Next
From: "Bossart, Nathan"
Date:
Subject: improve CREATE EXTENSION error message