Re: Memory use in 8.3 plpgsql with heavy use of xpath()

From: "Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Memory use in 8.3 plpgsql with heavy use of xpath()
Date: 2008-07-06 08:02:18
Message-ID: 49295.192.168.1.1.1215331338.squirrel@msqr.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> That's just a special case of what would be expected to happen with
>> memory
>> allocation anyways though. Few allocators return memory to the OS
>> anyways.
>
> Well, that does happen on Linux for instance. Since Matt knew in his
> original report that the xpath leak was intra-transaction, I assumed
> he must be using a platform where malloc/free can release memory back
> to the OS --- else he couldn't have seen that behavior from outside
> the backend.
>
> Still, it's entirely possible that some sort of high-water-mark is
> involved somewhere, perhaps in malloc's internal data structures.

I was really going on a hunch, as I noticed a definite trend of postgres
processes using more and more memory over time, and it only started after
switching to 8.3 and starting to use xpath() quite heavily. Most of the
memory data I have comes from Linux x64 systems with Postgres compiled as
64-bit. But I did also notice what appeared to be a similar trend on an OS
X PPC system.

In any event, I'm sorry I can't provide any more helpful tests, but I'll
report back how the system changes after I've patched these systems.

-- m@

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dave Page 2008-07-06 10:56:14 Re: Query Problem
Previous Message Tom Lane 2008-07-06 05:43:43 Re: roll back to 8.1 for PyQt driver work-around