Re: dblink() cursor error/issue (TopMemoryContext)

From: "Henry - Zen Search SA" <henry(at)zen(dot)co(dot)za>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: dblink() cursor error/issue (TopMemoryContext)
Date: 2008-06-13 14:46:15
Message-ID: 392db3c9daf7f8a056ae60e8d050d6ae.squirrel@zenmail.co.za
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, June 2, 2008 6:53 pm, Tom Lane wrote:
> I don't think your problem has anything to do with dblink per se.
> The repeated begin/exception blocks are apparently managing to leak
> some memory per iteration. I can't tell whether this represents
> a known (and perhaps already fixed) bug; it very likely depends on
> details you haven't shown us. Do you want to try to put together a
> self-contained test case?

Sorry for the delay in responding to this.

It looks like there's definitely a memory leak problem in 8.2.6 when
executing begin/exception in a loop.

After upgrading to 8.3.1, the same code ran to conclusion without error.

One other thing: the docs mention that functions use cursors
automatically to prevent OOM errors on large selects (as in my case).
Well, the second part of my function does this:

FOR rec in SELECT * FROM bigtable
LOOP
...begin/insert/exception...
END LOOP;

and bang, OOM. This is in 8.3.1. I'll rewrite this to use cursors, but
was hoping to take advantage of the implicit cursors to keep the code nice
and simple... or am I misunderstanding "...FOR loops automatically use a
cursor internally to avoid memory problems." from section 37.8 in the
manual?

Regards
Henry

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Henry - Zen Search SA 2008-06-13 16:27:47 Re: dblink() cursor error/issue (TopMemoryContext)
Previous Message Niederland 2008-06-13 14:02:37 Re: Win32 8.3.3 install fail (sufficient privileges to install system services).