"Matt Magoffin" <[EMAIL PROTECTED]> writes:
> Later, I added a large set of plpgsql trigger functions that operate on
> that new xml column data, using the xpath() function to extract bits of
> XML and populate them into normal tables. The server has been running in
> this fashion for many months now, and there is a noticeable difference in
> how Postgres is using memory now, in that over time it's non-shared memory
> use is climbing higher and higher. Right now I'm tracking this from data
> captured by Munin on the system. The memory creep is very slight, but over
> many months is easy to discern.
Looking back, I'm not sure that what we just found explains that part
of your original report.
> If I run some of these plpgsql functions using a lot of xpath() calls on
> large sets of data, huge amounts of memory are consumed (gigabytes) and
> the memory seems to accumulate until the transaction the functions are
> running in completes.
This part seems to match the bug though --- the leak is approximately
the same size as all the text returned by xpath() within the current
transaction.
So there may be a second issue remaining to be found. Can you put
together a test case for the long-term small leak?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
