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

Поиск
Список
Период
Сортировка
От Henry - Zen Search SA
Тема Re: dblink() cursor error/issue (TopMemoryContext)
Дата
Msg-id 392db3c9daf7f8a056ae60e8d050d6ae.squirrel@zenmail.co.za
обсуждение исходный текст
Ответ на Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: file system level backup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: dblink() cursor error/issue (TopMemoryContext)