Re: Preventing tuple-table leakage in plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Chad Wagner <chad(dot)wagner(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Preventing tuple-table leakage in plpgsql
Date: 2013-07-21 15:13:09
Message-ID: 5064.1374419589@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Jul 11, 2013 at 09:14:38PM -0400, Chad Wagner wrote:
>> 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.

That sounds like a dangerous idea to me. The procedure would then be
working actively with queries from two different SPI levels, which I'm
pretty sure would cause issues. It's possible that plpgsql's SPI access
is sufficiently lexically-local that statements within the BEGIN block
couldn't use any SPI resources created by statements outside it nor vice
versa. But then again maybe not, and in any case we couldn't imagine
that that would be a workable restriction for non-plpgsql scenarios.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-07-21 15:19:32 Re: Preventing tuple-table leakage in plpgsql
Previous Message Noah Misch 2013-07-21 14:59:23 Re: Preventing tuple-table leakage in plpgsql