Skip site navigation (1) Skip section navigation (2)

Re: Bug #933: Too many inserts crash server

From: Mark Pether <mutex(at)redsheriff(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug #933: Too many inserts crash server
Date: 2003-04-07 12:50:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

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:


do loop
    if loop % 16834 == 0
    end if
end loop;


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

Mark Pether.

Tom Lane wrote:

>pgsql-bugs(at)postgresql(dot)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

In response to


pgsql-bugs by date

Next:From: Mark PetherDate: 2003-04-07 13:27:07
Subject: Re: Bug #933: Too many inserts crash server
Previous:From: pgsql-bugsDate: 2003-04-07 11:18:07
Subject: Bug #936: pq_flush: send() failed on big query

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group