Re: Postmaster Out of Memory

Tom Lane wrote:
> I suppose what we are looking at here is some operation that is
> invalidating a relcache entry but failing to clear it.

Hm.  After discussing this with people here we have a hypothesis.  The
process that issues the TRUNCATE command does something a little
peculiar: every minute or so twelve distinct functions are overwritten
using CREATE OR REPLACE FUNCTION.  Perhaps this is causing the
postmaster backend to fill its relcache.

To test this Joe created a simple C program that does the same operation
on slightly changed functions (changed only enough so as not to
interfere with the real process).  After running this for a little over
an hour here is what we see from top:

   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
17033 postgres  16   0  182M 182M  180M R    35.7  4.6  22:33   1 postmaster
17032 root       9   0 63056  61M  1336 S     0.5  1.5   0:21   0
test_function

The RSS value has been steadily growing the entire time, so I think we
have our cause.  Is this a postmaster memory leak, or is this behavior
intentional?  Either way, what would be the best way to work around it?
  These functions are created in this way because we want them to point
to different tables at different times.

Thanks again for pointing us in the right direction on this.

                                                Jeff