Re: dblink() cursor error/issue (TopMemoryContext) - Mailing list pgsql-general

From Henry - Zen Search SA
Subject Re: dblink() cursor error/issue (TopMemoryContext)
Date
Msg-id 392db3c9daf7f8a056ae60e8d050d6ae.squirrel@zenmail.co.za
Whole thread Raw
In response to Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: file system level backup
Next
From: Tom Lane
Date:
Subject: Re: dblink() cursor error/issue (TopMemoryContext)