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 see. I didn't realize that unnamed cursors are still accessible to
anyone with the "<unnamed portal X>" name.
On the performance end, redoing SPI_cursor_find every row seems like
rather a large penalty ...
Granted.
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 new "pinned" state,
which is like PORTAL_READY except that the portal can't be dropped like
in PORTAL_ACTIVE state.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
