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

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

"Henry - Zen Search SA" <henry(at)zen(dot)co(dot)za> writes:
> 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.

How soon is "bang"? The above causes one subtransaction to be
instantiated per loop execution, since we have to have a new XID
for each inserted row (else it's not possible to roll back just
that row on failure). The memory overhead per subtransaction is
not zero, though I think it's fairly small if you don't have any
triggers pending as a result of the insert. (Hm ... any foreign
keys on the table being inserted into?)

> 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?

The FOR loop is not your problem.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Regan 2008-06-13 17:24:28 Source RPM for 8.3.3?
Previous Message Henry - Zen Search SA 2008-06-13 16:27:47 Re: dblink() cursor error/issue (TopMemoryContext)