These numbers don't even have any demonstrable connection to Postgres,
let alone to an xpath-related memory leak. You're going to need to come
up with a concrete test case if you want anyone to investigate.
regards, tom lane
As I said in the start of this thread, this
Gregory Stark [EMAIL PROTECTED] 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
Matt Magoffin [EMAIL PROTECTED] writes:
I'm following up on this thread from a month ago on PG 8.3 memory use. I'm
afraid even after updating to 8.3.3 + this patch, I still see the same
overall memory trend. You can see what I'm looking at here with a couple
of memory graphs.
These numbers
Gregory Stark [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
Well, you tell me --- *you* reported a behavior that isn't obviously
explained by the bug we found.
In case it wasn't clear, the bug found was a intra-transaction memory leak.
When the transaction ended the memory would be reclaimed. That doesn't seem to
Gregory Stark [EMAIL PROTECTED] 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
OK, I'll try to come up with something. Do you have a recommended way of
capturing the amount memory being used by Postgres related to this? I
was
thinking I would have a plpgsql function that loops a large number of
times, calling a few xpath() calls,
Yeah, that's what I'd try first.
Matt Magoffin [EMAIL PROTECTED] writes:
Below is a test case that simulates the use of xpath() within a plpgsql
function in my application.
I'm able to duplicate the memory leak in this function with the current
Fedora 8 libxml2 (2.6.32). The leak is definitely inside libxml2
itself, because
I looked through the libxml2 sources a little bit but couldn't
immediately find the problem. I'm fairly confident though that
this could be reproduced outside Postgres, by replicating the sequence
of libxml2 calls we make in xpath(). The next step should probably be
to build a reproducer
On Wed, 2 Jul 2008, Tom Lane wrote:
Matt Magoffin [EMAIL PROTECTED] writes:
Below is a test case that simulates the use of xpath() within a plpgsql
function in my application.
I'm able to duplicate the memory leak in this function with the current
Fedora 8 libxml2 (2.6.32). The leak is
I'm able to duplicate the memory leak in this function with the current
Fedora 8 libxml2 (2.6.32). The leak is definitely inside libxml2
itself, because the bloat shows up here:
I think this should fix it.
Kris Jurka
It looks like xml.c source has changed considerably since 8.3 (looking
Matt Magoffin [EMAIL PROTECTED] writes:
It looks like xml.c source has changed considerably since 8.3
No, hardly at all actually, but this patch happens to be right next door
to one of the lines that did change. cstring_to_text() replaces some
grottier stuff that used to be used for the same
I think this should fix it.
Kris Jurka
It looks like xml.c source has changed considerably since 8.3 (looking at
revision 1.68.2.2 from the 8.3.3. release). Do you know where/if this
patch would apply to the 8.3 branch?
I diff'ed 1.74 and 1.68.2.2, and I'm guessing this new line could be
Matt Magoffin [EMAIL PROTECTED] writes:
I think this should fix it.
Kris Jurka
Confirmed, that makes it go away nicely here:
LibxmlContext: 57344 total in 3 blocks; 55720 free (202 chunks); 1624 used
It looks like xml.c source has changed considerably since 8.3 (looking at
revision
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
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?
Matt Magoffin [EMAIL PROTECTED] writes:
So there may be a second issue remaining to be found. Can you put
together a test case for the long-term small leak?
Hmm, I'm not sure what else to add to this test case. This test case was a
good example of what our database is doing with xpath(); it
Probably the right thing for you to do now is just to install the known
fix, and keep an eye on your server for awhile to see if you still see
any indication of the long-term leak behavior.
Certainly, that is my plan. Once I can get the patch rolled out to these
systems, I should be able to
I've been using Postgres 8.3 in a production environment for some time
now, and have noticed a difference in long-term non-shared memory use by
Postgres since upgrading the system from 8.1. After initially making the
switch to 8.3 and making only one schema change (changed a text column to
xml)
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
Ugh. Sounds like small memory leak inside libxml2 --- probably not
going to be easy to find. Can you put together a self-contained test
case?
OK, I'll try to come up with something. Do you have a recommended way of
capturing the amount memory being used by Postgres related to this? I was
Matt Magoffin [EMAIL PROTECTED] writes:
Ugh. Sounds like small memory leak inside libxml2 --- probably not
going to be easy to find. Can you put together a self-contained test
case?
OK, I'll try to come up with something. Do you have a recommended way of
capturing the amount memory being
22 matches
Mail list logo
