<!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/rollback_to.sgml,v 1.5 2004/11/27 21:27:07 petere Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/rollback_to.sgml,v 1.6 2005/01/26 23:20:20 tgl Exp $
PostgreSQL documentation
-->
<para>
Cursors have somewhat non-transactional behavior with respect to
- savepoints. Any cursor that is opened inside the savepoint is not closed
- when the savepoint is rolled back. If a cursor is affected by a
+ savepoints. Any cursor that is opened inside a savepoint will be closed
+ when the savepoint is rolled back. If a previously opened cursor is
+ affected by a
<command>FETCH</> command inside a savepoint that is later rolled
back, the cursor position remains at the position that <command>FETCH</>
left it pointing to (that is, <command>FETCH</> is not rolled back).
+ Closing a cursor is not undone by rolling back, either.
A cursor whose execution causes a transaction to abort is put in a
can't-execute state, so while the transaction can be restored using
<command>ROLLBACK TO SAVEPOINT</>, the cursor can no longer be used.
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/utils/mmgr/portalmem.c,v 1.76 2004/12/31 22:02:48 pgsql Exp $
+ * $PostgreSQL: pgsql/src/backend/utils/mmgr/portalmem.c,v 1.77 2005/01/26 23:20:21 tgl Exp $
*
*-------------------------------------------------------------------------
*/
/*
* Subtransaction abort handling for portals.
*
- * Deactivate failed portals created during the failed subtransaction.
+ * Deactivate portals created during the failed subtransaction.
* Note that per AtSubCommit_Portals, this will catch portals created
* in descendants of the subtransaction too.
+ *
+ * We don't destroy any portals here; that's done in AtSubCleanup_Portals.
*/
void
AtSubAbort_Portals(SubTransactionId mySubid,
* will go FAILED if the underlying cursor fails. (Note we do NOT
* want to do this to upper-level portals, since they may be able
* to continue.)
+ *
+ * This is only needed to dodge the sanity check in PortalDrop.
*/
if (portal->status == PORTAL_ACTIVE)
portal->status = PORTAL_FAILED;
/*
* If the portal is READY then allow it to survive into the parent
* transaction; otherwise shut it down.
+ *
+ * Currently, we can't actually support that because the portal's
+ * query might refer to objects created or changed in the failed
+ * subtransaction, leading to crashes if execution is resumed.
+ * So, even READY portals are deleted. It would be nice to detect
+ * whether the query actually depends on any such object, instead.
*/
+#ifdef NOT_USED
if (portal->status == PORTAL_READY)
{
portal->createSubid = parentSubid;
ResourceOwnerNewParent(portal->resowner, parentXactOwner);
}
else
+#endif
{
/* let portalcmds.c clean up the state it knows about */
if (PointerIsValid(portal->cleanup))