Re: Bug in PL/pgSQL FOR cursor variant - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug in PL/pgSQL FOR cursor variant
Date
Msg-id 16598.1277148314@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in PL/pgSQL FOR cursor variant  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Bug in PL/pgSQL FOR cursor variant  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 21/06/10 17:08, Tom Lane wrote:
>> Also, isn't exec_for_query() at just as much risk?
>> The latter's problem would only be exposed if the cursor was closed
>> at a batch boundary, but it's still a problem.

> Can you elaborate? I thought I fixed exec_for_query(). (except for the
> missing pstrdup).

Oh, I thought I'd read the whole patch, but I see I missed the last
part.  But it doesn't matter, because that's still broken, both as to
performance and security.  prefetch_ok is not meant to be bulletproof,
only to ensure that in cases where the cursor is *meant* to be exposed
to the user its behavior is as he expects.  If you're trying to stop a
crash you need to realize that people can get at any portal at all.
On the performance end, redoing SPI_cursor_find every row seems like
rather a large penalty ...

            regards, tom lane

pgsql-bugs by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: BUG #5519: uuid-ossp files missing from contrib rpm
Next
From: Dave Page
Date:
Subject: Re: BUG #5518: MS crash - can duplicate every time