From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Memory use in 8.3 plpgsql with heavy use of xpath() |
Date: | 2008-07-03 03:55:54 |
Message-ID: | 22701.1215057354@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us> 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 is using quite
> a number of them, that's all. Is there something else in particular you'd
> be looking for in another test case?
Well, you tell me --- *you* reported a behavior that isn't obviously
explained by the bug we found.
It's possible that what you were seeing was an indirect effect of the
now-known bug: if the xpath leak were to occur repeatedly on a large
scale in a long-lived session, I think it's possible that memory
allocation behavior might suffer due to fragmentation effects.
I feel that that's a pretty hand-wavy explanation though.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-07-03 04:02:32 | Re: pg_dump - lost synchronization with server: got message type "d", length 6036499 |
Previous Message | Brian A. Seklecki (Mobile) | 2008-07-03 02:50:35 | Re: LDAP Authentication |