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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
