From d780f07ac1ea97e2d3cf906cc1c9d59d6b21c5e2 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 2 Dec 2005 20:03:42 +0000 Subject: Adjust scan plan nodes to avoid getting an extra AccessShareLock on a relation if it's already been locked by execMain.c as either a result relation or a FOR UPDATE/SHARE relation. This avoids an extra trip to the shared lock manager state. Per my suggestion yesterday. --- src/backend/executor/nodeBitmapIndexscan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'src/backend/executor/nodeBitmapIndexscan.c') diff --git a/src/backend/executor/nodeBitmapIndexscan.c b/src/backend/executor/nodeBitmapIndexscan.c index 46e8c146521..4217de39522 100644 --- a/src/backend/executor/nodeBitmapIndexscan.c +++ b/src/backend/executor/nodeBitmapIndexscan.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/nodeBitmapIndexscan.c,v 1.12 2005/11/25 19:47:49 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/executor/nodeBitmapIndexscan.c,v 1.13 2005/12/02 20:03:40 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -286,8 +286,8 @@ ExecInitBitmapIndexScan(BitmapIndexScan *node, EState *estate) /* * We do not open or lock the base relation here. We assume that an - * ancestor BitmapHeapScan node is holding AccessShareLock on the heap - * relation throughout the execution of the plan tree. + * ancestor BitmapHeapScan node is holding AccessShareLock (or better) + * on the heap relation throughout the execution of the plan tree. */ indexstate->ss.ss_currentRelation = NULL; -- cgit v1.2.3