diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2001-06-01 02:41:36 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2001-06-01 02:41:36 +0000 |
| commit | 0b370ea7c81228339da5a447057dbf5f874e0197 (patch) | |
| tree | 125c8590975f212a7caec6667f95f28d772bb928 /src/backend/access/index/istrat.c | |
| parent | a1d9d096f0f36afcdd4ca69afb41cd645b9834d2 (diff) | |
| download | postgresql-0b370ea7c81228339da5a447057dbf5f874e0197.tar.gz | |
Clean up some minor problems exposed by further thought about Panon's bug
report on old-style functions invoked by RI triggers. We had a number of
other places that were being sloppy about which memory context FmgrInfo
subsidiary data will be allocated in. Turns out none of them actually
cause a problem in 7.1, but this is for arcane reasons such as the fact
that old-style triggers aren't supported anyway. To avoid getting burnt
later, I've restructured the trigger support so that we don't keep trigger
FmgrInfo structs in relcache memory. Some other related cleanups too:
it's not really necessary to call fmgr_info at all while setting up
the index support info in relcache entries, because those ScanKeyEntry
structs are never used to invoke the functions. This should speed up
relcache initialization a tiny bit.
Diffstat (limited to 'src/backend/access/index/istrat.c')
| -rw-r--r-- | src/backend/access/index/istrat.c | 34 |
1 files changed, 28 insertions, 6 deletions
diff --git a/src/backend/access/index/istrat.c b/src/backend/access/index/istrat.c index 8cd1284972..188f69b571 100644 --- a/src/backend/access/index/istrat.c +++ b/src/backend/access/index/istrat.c @@ -9,7 +9,7 @@ * * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/backend/access/index/Attic/istrat.c,v 1.50 2001/05/30 19:53:40 tgl Exp $ + * $Header: /cvsroot/pgsql/src/backend/access/index/Attic/istrat.c,v 1.51 2001/06/01 02:41:35 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -458,6 +458,8 @@ RelationInvokeStrategy(Relation relation, /* ---------------- * OperatorRelationFillScanKeyEntry + * + * Initialize a ScanKey entry given already-opened pg_operator relation. * ---------------- */ static void @@ -498,6 +500,7 @@ OperatorRelationFillScanKeyEntry(Relation operatorRelation, operatorObjectId); } + MemSet(entry, 0, sizeof(*entry)); entry->sk_flags = 0; entry->sk_procedure = ((Form_pg_operator) GETSTRUCT(tuple))->oprcode; @@ -511,14 +514,29 @@ OperatorRelationFillScanKeyEntry(Relation operatorRelation, "OperatorRelationFillScanKeyEntry: no procedure for operator %u", operatorObjectId); - fmgr_info(entry->sk_procedure, &entry->sk_func); - entry->sk_nargs = entry->sk_func.fn_nargs; + /* + * Formerly we initialized entry->sk_func here, but that's a waste of + * time because ScanKey entries in strategy maps are never actually + * used to invoke the operator. Furthermore, to do that we'd have to + * worry about setting the proper memory context (the map is probably + * not allocated in the current memory context!) + */ } /* * IndexSupportInitialize * Initializes an index strategy and associated support procedures. + * + * Data is returned into *indexStrategy, *indexSupport, and *isUnique, + * all of which are objects allocated by the caller. + * + * The primary input keys are indexObjectId and accessMethodObjectId. + * The caller also passes maxStrategyNumber, maxSupportNumber, and + * maxAttributeNumber, since these indicate the size of the indexStrategy + * and indexSupport arrays it has allocated --- but in practice these + * numbers must always match those obtainable from the system catalog + * entries for the index and access method. */ void IndexSupportInitialize(IndexStrategy indexStrategy, @@ -578,7 +596,7 @@ IndexSupportInitialize(IndexStrategy indexStrategy, if (!OidIsValid(iform->indkey[attIndex])) { if (attIndex == InvalidAttrNumber) - elog(ERROR, "IndexSupportInitialize: no pg_index tuple"); + elog(ERROR, "IndexSupportInitialize: bogus pg_index tuple"); break; } @@ -637,6 +655,7 @@ IndexSupportInitialize(IndexStrategy indexStrategy, heap_close(relation, AccessShareLock); } + /* Now load the strategy information for the index operators */ ScanKeyEntryInitialize(&entry[0], 0, Anum_pg_amop_amopid, F_OIDEQ, @@ -644,7 +663,8 @@ IndexSupportInitialize(IndexStrategy indexStrategy, ScanKeyEntryInitialize(&entry[1], 0, Anum_pg_amop_amopclaid, - F_OIDEQ, 0); + F_OIDEQ, + 0); /* will fill below */ relation = heap_openr(AccessMethodOperatorRelationName, AccessShareLock); operatorRelation = heap_openr(OperatorRelationName, AccessShareLock); @@ -670,9 +690,11 @@ IndexSupportInitialize(IndexStrategy indexStrategy, Form_pg_amop aform; aform = (Form_pg_amop) GETSTRUCT(tuple); + strategy = aform->amopstrategy; + Assert(strategy > 0 && strategy <= maxStrategyNumber); OperatorRelationFillScanKeyEntry(operatorRelation, aform->amopopr, - StrategyMapGetScanKeyEntry(map, aform->amopstrategy)); + StrategyMapGetScanKeyEntry(map, strategy)); } heap_endscan(scan); |
