On 05/09/2012 10:01 PM, Tom Lane wrote:
> Joe Conway writes:
>> The attached one-liner seems to plug up the majority (although not quite
>> all) of the leakage.
>
> Looks sane to me. Are you planning to look for the remaining leakage?
Actually, now I'm not so sure there really are any other lea
Joe Conway writes:
> The attached one-liner seems to plug up the majority (although not quite
> all) of the leakage.
Looks sane to me. Are you planning to look for the remaining leakage?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On 05/09/2012 05:06 PM, Joe Conway wrote:
> OK, new script. This more faithfully represents the real life scenario,
> and reproduces the issue on HEAD with out-of-the-box config settings,
> versus 8.1 which completes the query having never exceeded a very modest
> memory usage:
>
> ---
On 05/09/2012 03:36 PM, Joe Conway wrote:
> Good call -- of course that just means my contrived example fails to
> duplicate the real issue :-(
> In the real example, even with work_mem = 1 MB I see the same behavior
> on 9.1.
OK, new script. This more faithfully represents the real life scenario,
On 05/09/2012 03:08 PM, Tom Lane wrote:
> I see no memory leak at all in this example, either in HEAD or 9.1
> branch tip. Perhaps whatever you're seeing is an already-fixed bug?
>
> Another likely theory is that you've changed settings from the 8.1
> installation. I would expect this example to
Joe Conway writes:
> I'm working on an upgrade of PostgreSQL embedded in a product from
> version 8.1.x to 9.1.x. One particular PL/pgSQL function is giving us an
> issue as there seems to be a rather severe regression in memory usage --
> a query that finishes in 8.1 causes an out of memory excep
I'm working on an upgrade of PostgreSQL embedded in a product from
version 8.1.x to 9.1.x. One particular PL/pgSQL function is giving us an
issue as there seems to be a rather severe regression in memory usage --
a query that finishes in 8.1 causes an out of memory exception on 9.1.
Using the same