Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
In response to
pgsql-bugs by date
|Next:||From: Dave Page||Date: 2010-06-21 19:56:40|
|Subject: Re: BUG #5518: MS crash - can duplicate every time|
|Previous:||From: Devrim GÜNDÜZ||Date: 2010-06-21 18:44:57|
|Subject: Re: BUG #5519: uuid-ossp files missing from contrib rpm|