On 13 November 2013 03:17 David Johnston wrote,
>
> Having had this same thought WRT the "FOR UPDATE in LOOP" bug posting
> the lack of a listing of outstanding bugs does leave some gaps. I
> would imagine people would appreciate something like:
>
> Frequency: Rare
> Severity: Low
> Fix Complex
On 2013-11-14 22:23, Tom Lane wrote:
So after some experimentation I came up with version 2, attached.
Thanks for looking into this! I currently do not have access to a setup
to try the patch. A colleague of mine will look into this next week.
Thanks again,
Yeb Havinga
--
Sent via pgsql-h
I wrote:
> Robert Haas writes:
>> I'm not volunteering to spend time fixing this, but I disagree with
>> the premise that it isn't worth fixing, because I think it's a POLA
>> violation.
> Yeah, I'm not terribly comfortable with letting it go either. Attached
> is a proposed patch. I couldn't s
Robert Haas writes:
> On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane wrote:
>> Or we could say "what the heck are you doing executing tens of
>> thousands of DO blocks? Make it into a real live function;
>> you'll save a lot of cycles on parsing costs." I'm not sure that
>> this is a usage pattern
Robert Haas wrote
> That's a sufficiently astonishing result that it wouldn't be
> surprising for this to get reported as a bug where a simple
> performance gap wouldn't be, and I think if we don't fix it the
> perception will be that we've left that bug unfixed. Now, there are
> lots of things we
On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane wrote:
> Or we could say "what the heck are you doing executing tens of
> thousands of DO blocks? Make it into a real live function;
> you'll save a lot of cycles on parsing costs." I'm not sure that
> this is a usage pattern we ought to be optimizing f
On 2013-11-12 11:18:32 -0500, Tom Lane wrote:
> Or we could say "what the heck are you doing executing tens of
> thousands of DO blocks? Make it into a real live function;
> you'll save a lot of cycles on parsing costs." I'm not sure that
> this is a usage pattern we ought to be optimizing for.
I spent a bit of time looking into the memory leak reported here:
http://www.postgresql.org/message-id/52376c35.5040...@gmail.com
I think this test case doesn't have much to do with the complainant's
original problem, but anyway it is exposing a genuine leakage issue.
The difficulty is that when p
