Re: Preventing tuple-table leakage in plpgsql

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Preventing tuple-table leakage in plpgsql
Дата
Msg-id 20130721145923.GA126339@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Preventing tuple-table leakage in plpgsql  (Chad Wagner <chad.wagner@gmail.com>)
Ответы Re: Preventing tuple-table leakage in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jul 11, 2013 at 09:14:38PM -0400, Chad Wagner wrote:
> It looks like to me when AtEOSubXact_SPI is called the
> _SPI_current->connectSubId is always 1 (since it is only set when
> SPI_connect is called, which is only once for plpgsql), but the
> CurrentSubTransactionId is incremented each time a subtransaction is
> started.

Right.  AtEOSubXact_SPI() cleans up any SPI connections originating in the
ending subtransaction.  It leaves alone connections from higher subtransaction
levels; SPI has no general expectation that those have lost relevance.

> As a result, the memory for procCxt is only freed when I presume the
> TopTransaction is aborted or committed.

In your code from bug #8279, I expect it to be freed when the DO block exits.
The backend might not actually shrink then, but repeated calls to a similar DO
block within the same transaction should not cause successive increases in the
process's memory footprint.

> Should SPI_connect be called again after the subtransaction is created?  And
>  SPI_finish before the subtransaction is committed or aborted?

Hmm.  An SPI_push()+SPI_connect() every time PL/pgSQL starts a subtransaction
would be another way to fix it, yes.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



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

Предыдущее
От: Миша Тюрин
Дата:
Сообщение: Auto explain target tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Preventing tuple-table leakage in plpgsql