database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-07 19:06:32 +03:00
Code Activity

Avoid redundant relation lock grabs during planning, and make sure

Browse Source 
that we acquire a lock on relations added to the query due to inheritance.
Formerly, no such lock was held throughout planning, which meant that
a schema change could occur to invalidate the plan before it's even
been completed.
This commit is contained in:
Tom Lane
2005-05-23 03:01:14 +00:00
parent 353f111f98
commit c1393173aa
3 changed files with 40 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/optimizer/prep/preptlist.c
View File

@@ -15,7 +15,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.75 2005/04/28 21:47:14 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.76 2005/05/23 03:01:13 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -189,9 +189,11 @@ expand_targetlist(List *tlist, int command_type,
* attributes.
*
* Scan the tuple description in the relation's relcache entry to make
* sure we have all the user attributes in the right order.
* sure we have all the user attributes in the right order. We assume
* that the rewriter already acquired at least AccessShareLock on the
* relation, so we need no lock here.
*/
rel = heap_open(getrelid(result_relation, range_table), AccessShareLock);
rel = heap_open(getrelid(result_relation, range_table), NoLock);
numattrs = RelationGetNumberOfAttributes(rel);
@@ -326,7 +328,7 @@ expand_targetlist(List *tlist, int command_type,
tlist_item = lnext(tlist_item);
}
heap_close(rel, AccessShareLock);
heap_close(rel, NoLock);
return new_tlist;
}