Tom Lane escribió: > Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
