Skip site navigation (1) Skip section navigation (2)

Re: Bug in PL/pgSQL FOR cursor variant

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Bug in PL/pgSQL FOR cursor variant
Date: 2010-06-21 19:25:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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 PageDate: 2010-06-21 19:56:40
Subject: Re: BUG #5518: MS crash - can duplicate every time
Previous:From: Devrim GÜNDÜZDate: 2010-06-21 18:44:57
Subject: Re: BUG #5519: uuid-ossp files missing from contrib rpm

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group