On 22/06/10 01:49, Heikki Linnakangas wrote:
On 22/06/10 00:47, Heikki Linnakangas wrote:
Maybe it would be easier to somehow protect the portal then, and throw
an error if you try to close it. We could just mark the portal as
PORTAL_ACTIVE while we run the user statements, but that would also
f
Excerpts from Heikki Linnakangas's message of lun jun 21 18:29:48 -0400 2010:
> On 22/06/10 00:59, Alvaro Herrera wrote:
> > Excerpts from Heikki Linnakangas's message of lun jun 21 17:47:43 -0400
> > 2010:
> >
> >> Maybe it would be easier to somehow protect the portal then, and throw
> >> an err
On 22/06/10 00:47, Heikki Linnakangas wrote:
Maybe it would be easier to somehow protect the portal then, and throw
an error if you try to close it. We could just mark the portal as
PORTAL_ACTIVE while we run the user statements, but that would also
forbid fetching or moving it. I'm thinking of a
On 22/06/10 00:59, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of lun jun 21 17:47:43 -0400 2010:
Maybe it would be easier to somehow protect the portal then, and throw
an error if you try to close it. We could just mark the portal as
PORTAL_ACTIVE while we run the user sta
Excerpts from Heikki Linnakangas's message of lun jun 21 17:47:43 -0400 2010:
> Maybe it would be easier to somehow protect the portal then, and throw
> an error if you try to close it. We could just mark the portal as
> PORTAL_ACTIVE while we run the user statements, but that would also
> forb
On 21/06/10 22:25, Tom Lane wrote:
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.
Oh, I
Heikki Linnakangas 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(). (
On 21/06/10 17:08, Tom Lane wrote:
I suspect you need to pstrdup() the portalname.
Yes, you're right. Thanks.
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 elabora
Heikki Linnakangas writes:
> The problem is that exec_stmt_forc keeps using a pointer to the Portal,
> which becomes invalid if the cursor is closed in the middle. Patch
> attached, will apply..
Does that really fix anything? I suspect you need to pstrdup() the
portalname. Also, isn't exec_fo
