Re: Weird behavior with "sensitive" cursors.

Tom Lane escribió:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Interesting.  If I create an non-unique index on the table before
> > declaring the cursor, FETCH throws an error:
>
> > alvherre=# fetch all from c1;
> > ERROR:  attempted to lock invisible tuple
>
> I get that in 8.4 and HEAD even without any index, just trying the given
> case.  It looks to me like this is a bug in the new snapshot management.
> The cursor is using CurrentSnapshot directly --- it does not have a
> private copy --- and therefore when CommandCounterIncrement happens
> it affects what the cursor can "see".  The cursor should not be able
> to "see" any tuples created after it was created.

Right, but what if it tries to grab a tuple that was updated?  When the
portal tries to fetch the tuple, it has become "invisible", thus the
error, no?

> I think we need to ensure that when a cursor is created, it obtains a
> private copy of the current snapshot ... but I'm not sure where that
> ought to happen.  Thoughts?

Maybe you are right, but I don't think that's the only bug here.

I think the right place is PerformCursorOpen; instead of having
PortalStart use GetActiveSnapshot(), it should create a copy of it.  The
first problem is that we don't have any API in snapmgr.c for this "gimme
a private copy of this snap"; I think we'll have to open up CopySnapshot
to outside calls :-(

I played a bit with doing this only when the OPT_CURSOR_INSENSITIVE bit
is set, but I'm not ever seeing it set -- with or with FOR UPDATE ...

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.