Re: [HACKERS] [GENERAL] Memory Errors...
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] [GENERAL] Memory Errors... |
Дата | |
Msg-id | 200209230146.g8N1kEW17923@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] [GENERAL] Memory Errors... ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Список | pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --------------------------------------------------------------------------- Nigel J. Andrews wrote: > On Thu, 19 Sep 2002, Tom Lane wrote: > > > "Ian Harding" <ianh@tpchd.org> writes: > > > It is pltcl [not plpgsql] > > > > Ah. I don't think we've done much of any work on plugging leaks in > > pltcl :-(. > > > > > It hurts when I do this: > > > > > drop function memleak(); > > > create function memleak() returns int as ' > > > for {set counter 1} {$counter < 100000} {incr counter} { > > > set sql "select ''foo''" > > > spi_exec "$sql" > > > } > > > ' language 'pltcl'; > > > select memleak(); > > > > Yeah, I see very quick memory exhaustion also :-(. Looks like the > > spi_exec call is the culprit, but I'm not sure exactly why ... > > anyone have time to look at this? > > Attached is a patch that frees the SPI_tuptable in all post SPI_exec > non-elog paths in both pltcl_SPI_exec() and pltcl_SPI_execp(). > > The fault as triggered by the above code has been fixed by this patch but > please read my assumptions below to ensure they are correct. > > I have assumed that Tom's comment about this only being required in non-elog > paths is correct, which seems a reasonable assumption to me. > > I have also assumed, rather than verified, that freeing the tuptable does > indeed free the tuples as well. Tests with the above function show that the > process does not increase it's memory footprint during it's operation, although > if my assumption here is wrong this could be a feature of selecting > insignificantly sized tuples. > > I have not worried about other uses of SPI_exec for selects in pltcl.c on the > basis that those are not under the control of the function writer and the > normal function management will release the storage. > > > -- > Nigel J. Andrews Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: