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

From Henry
Subject Re: dblink() cursor error/issue (TopMemoryContext)
Date
Msg-id 264f30190e8e59732ef0d1d2124e0d4a.squirrel@zenmail.co.za
Whole thread Raw
In response to 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:
> "Henry" <henry@zen.co.za> writes:
>> I'm trying to code a function to copy rows from one machine to another
>> using dblink and cursors:
>
> What PG version is this, exactly?

Arg, dammit.  Sorry, it's version 8.2.6 (where the function is running),
talking to a remote machine running 8.3.1.

> 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?  (Again, you likely don't need dblink to
> exhibit the issue.)

OK, will give this a swing; but I'll first upgrade to 8.3.1 and see what
that does.

> If you just want something that works now, try probing for an existing
> entry before inserting, instead of relying on catching an exception.

ok, but that's going to be slow considering I'm inserting almost a hundred
million rows.

My previous post wasn't entirely accurate:  the dblink_exec() call in a
loop is also enclosed in a begin/exception/end block, yet it doesn't fail.
 The only difference besides the dblink_exec call itself, is that I'm
using 'others' to catch any error from dblink_exec (using 'others' on the
first insert results in the same issue).




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: dblink() cursor error/issue (TopMemoryContext)
Next
From: "Peter Geoghegan"
Date:
Subject: Maintaining an index on a large table: Is there any potential for it to stall my application?