Re: Bug #933: Too many inserts crash server

Поиск
Список
Период
Сортировка
От Mark Pether
Тема Re: Bug #933: Too many inserts crash server
Дата
Msg-id 3E917401.80300@redsheriff.com
обсуждение исходный текст
Ответ на Re: Bug #933: Too many inserts crash server  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug #933: Too many inserts crash server
Список pgsql-bugs
Ok,

Thanks for advice I'll add SPI_freetuple() to my program.

I must say I had a difficult time trying to work around this problem
(couldn't find any docs),
so you may want to add note into Postgres 7.3 Server Programming docs.

By the way, my workaround successfully used was:

 SPI_push();
 SPI_connect();

do loop
    if loop % 16834 == 0
       SPI_finish()
       SPI_connect()
    end if
end loop;

SPI_finish()
SPI_pop();

This also freed memory, but doesn't look nice and uses the undoc'd push
and pop calls.

Regards,
Mark Pether.



Tom Lane wrote:

>pgsql-bugs@postgresql.org writes:
>
>
>>If I create an external C function consisting of a
>>simple loop that inserts 250000 records into a table
>>the server process eventually crashes.
>>
>>
>
>The memory leak goes away if you add
>
>    SPI_freetuptable(SPI_tuptable);
>
>after the SPI_exec() call.
>
>I am not sure whether to consider this an SPI bug or not.  It's possibly
>surprising that a non-SELECT query generates an empty tuple table; but
>on the other hand, it's hard to say that no non-SELECT query can ever
>generate a tuple table.  (EXPLAIN is a counterexample, for instance.)
>
>It may be better to document that you should always do
>SPI_freetuptable() no matter what kind of query you executed.
>
>            regards, tom lane
>
>
>
>

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Laura Moloney"
Дата:
Сообщение: bug with dump sql to recreate view
Следующее
От: Mark Pether
Дата:
Сообщение: Re: Bug #933: Too many inserts crash server