diff options
Diffstat (limited to 'src/backend/utils/mmgr/portalmem.c')
| -rw-r--r-- | src/backend/utils/mmgr/portalmem.c | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/src/backend/utils/mmgr/portalmem.c b/src/backend/utils/mmgr/portalmem.c index 9866e12d68c..8120720041b 100644 --- a/src/backend/utils/mmgr/portalmem.c +++ b/src/backend/utils/mmgr/portalmem.c @@ -12,7 +12,7 @@ * Portions Copyright (c) 1994, Regents of the University of California * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/utils/mmgr/portalmem.c,v 1.82 2005/10/15 02:49:36 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/utils/mmgr/portalmem.c,v 1.82.2.1 2005/11/22 18:23:25 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -320,21 +320,21 @@ PortalDrop(Portal portal, bool isTopCommit) * Release any resources still attached to the portal. There are several * cases being covered here: * - * Top transaction commit (indicated by isTopCommit): normally we should do - * nothing here and let the regular end-of-transaction resource releasing - * mechanism handle these resources too. However, if we have a FAILED - * portal (eg, a cursor that got an error), we'd better clean up its - * resources to avoid resource-leakage warning messages. + * Top transaction commit (indicated by isTopCommit): normally we should + * do nothing here and let the regular end-of-transaction resource + * releasing mechanism handle these resources too. However, if we have a + * FAILED portal (eg, a cursor that got an error), we'd better clean up + * its resources to avoid resource-leakage warning messages. * - * Sub transaction commit: never comes here at all, since we don't kill any - * portals in AtSubCommit_Portals(). + * Sub transaction commit: never comes here at all, since we don't kill + * any portals in AtSubCommit_Portals(). * * Main or sub transaction abort: we will do nothing here because * portal->resowner was already set NULL; the resources were already * cleaned up in transaction abort. * - * Ordinary portal drop: must release resources. However, if the portal is - * not FAILED then we do not release its locks. The locks become the + * Ordinary portal drop: must release resources. However, if the portal + * is not FAILED then we do not release its locks. The locks become the * responsibility of the transaction's ResourceOwner (since it is the * parent of the portal's owner) and will be released when the transaction * eventually ends. @@ -439,8 +439,8 @@ CommitHoldablePortals(void) * Instead of dropping the portal, prepare it for access by later * transactions. * - * Note that PersistHoldablePortal() must release all resources used - * by the portal that are local to the creating transaction. + * Note that PersistHoldablePortal() must release all resources + * used by the portal that are local to the creating transaction. */ PortalCreateHoldStore(portal); PersistHoldablePortal(portal); @@ -698,8 +698,8 @@ AtSubAbort_Portals(SubTransactionId mySubid, * 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 + * 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. |