"Nick Muerdter" <stuff@xxxxxxxxx> writes:
> I've been seeing what looks like unbounded memory growth (until the OOM killer kicks in and kills the postgres process) when running a pl/pgsql function that performs TRUNCATE statements against various temporary tables in a loop. I think I've been able to come up with some fairly simple reproductions of the issue in isolation, but I'm trying to figure out if this is a memory leak or of I'm perhaps doing something wrong with tuning or other settings.
Hmm, so the "leak" occurs here:
#0 AllocSetAlloc (context=0x2b70820, size=528) at aset.c:730
#1 0x00000000009617fc in MemoryContextAlloc (context=0x2b70820,
size=size@entry=528) at mcxt.c:875
#2 0x00000000009234b9 in AddInvalidationMessage (listHdr=0x2b70be8,
msg=msg@entry=0x7ffdb35893d0) at inval.c:244
#3 0x00000000009235c0 in AddRelcacheInvalidationMessage (relId=37554,
dbId=<optimized out>, hdr=<optimized out>) at inval.c:414
#4 RegisterRelcacheInvalidation (dbId=<optimized out>, relId=37554)
at inval.c:520
#5 0x0000000000923b87 in CacheInvalidateRelcacheByTuple (
classTuple=classTuple@entry=0x2bf82e8) at inval.c:1328
#6 0x00000000005da654 in index_update_stats (rel=0x7f23b49eb4d0,
hasindex=<optimized out>, reltuples=<optimized out>) at index.c:2872
#7 0x00000000005dbca2 in index_build (
heapRelation=heapRelation@entry=0x7f23b49eb4d0,
indexRelation=indexRelation@entry=0x7f23b49eb900,
indexInfo=indexInfo@entry=0x2bb5250, isreindex=isreindex@entry=true,
parallel=parallel@entry=false) at index.c:3051
#8 0x00000000005d66be in RelationTruncateIndexes (
heapRelation=heapRelation@entry=0x7f23b49eb4d0) at heap.c:3305
#9 0x00000000005d9875 in heap_truncate_one_rel (rel=rel@entry=0x7f23b49e72b0)
at heap.c:3387
#10 0x000000000068047f in ExecuteTruncateGuts (explicit_rels=0x2bb4b78,
relids=<optimized out>, relids_logged=0x0, behavior=DROP_RESTRICT,
restart_seqs=false) at tablecmds.c:1957
#11 0x0000000000680b65 in ExecuteTruncate (stmt=0x2bcd538) at tablecmds.c:1709
That is, we're accumulating a record of system catalog invalidation
events, which have to be kept until end of transaction when they'll
be sent out to other backends. (For the case of events on temp
tables, maybe that wouldn't be strictly necessary, but this certainly
can't be avoided for normal tables.) So it's not really a leak, but
just a record of unfinished work caused by the TRUNCATEs.
However ... what seems odd is that we only get an inval message when
there's an index involved. In principle such messages need to be
issued against the table as well. I suspect that we're optimizing
away the message for the table, either on the grounds that it's temp
or that it's new in the current transaction; but the index code path
didn't get the same TLC.
Alternatively, maybe it's a bug that there's no message for the table.
regards, tom lane
