NotificationsYou must be signed in to change notification settings
Fork6
Star31

Commit36786a8

committed

Fix nasty TRUNCATE bug reported by Darrin Ladd. RelationTruncateIndexes

would close and then re-open rel being truncated. Depending on theluck of the draw, the re-opened relcache entry might or might not beat the same physical location as before. Unfortunately, if it wasn'tthen heap_truncate would crash and burn, because it still had a pointerat the old location. Fix is to open and then close rel inRelationTruncateIndexes, so that rel's refcount never goes to zerountil heap_truncate is done.

1 parent0ba77c1 commit36786a8Copy full SHA for 36786a8

File tree

1 file changed

+24

-28

lines changed

src/backend/catalog
- heap.c

1 file changed

+24

-28

lines changed

`‎src/backend/catalog/heap.c`

Lines changed: 24 additions & 28 deletions

Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@`
`8`	`8`	`*`
`9`	`9`	`*`
`10`	`10`	`* IDENTIFICATION`
`11`		`- * $Header: /cvsroot/pgsql/src/backend/catalog/heap.c,v 1.145 2000/09/29 18:21:25 tgl Exp $`
	`11`	`+ * $Header: /cvsroot/pgsql/src/backend/catalog/heap.c,v 1.146 2000/09/30 18:28:53 tgl Exp $`
`12`	`12`	`*`
`13`	`13`	`*`
`14`	`14`	`* INTERFACE ROUTINES`
`@@ -1064,32 +1064,32 @@ DeleteRelationTuple(Relation rel)`
`1064`	`1064`	`* RelationTruncateIndexes - This routine is used to truncate all`
`1065`	`1065`	`* indices associated with the heap relation to zero tuples.`
`1066`	`1066`	`* The routine will truncate and then reconstruct the indices on`
`1067`		`- * the relation specified by theheapRelation parameter.`
	`1067`	`+ * the relation specified by theheapId parameter.`
`1068`	`1068`	`* --------------------------------`
`1069`	`1069`	`*/`
`1070`	`1070`	`staticvoid`
`1071`		`-RelationTruncateIndexes(RelationheapRelation)`
	`1071`	`+RelationTruncateIndexes(OidheapId)`
`1072`	`1072`	`{`
`1073`		`-RelationindexRelation,`
`1074`		`-currentIndex;`
	`1073`	`+RelationindexRelation;`
`1075`	`1074`	`ScanKeyDataentry;`
`1076`	`1075`	`HeapScanDescscan;`
`1077`		`-HeapTupleindexTuple,`
`1078`		`-classTuple;`
`1079`		`-IndexInfo*indexInfo;`
`1080`		`-OidheapId,`
`1081`		`-indexId,`
`1082`		`-accessMethodId;`
`1083`		`-`
`1084`		`-heapId=RelationGetRelid(heapRelation);`
	`1076`	`+HeapTupleindexTuple;`
`1085`	`1077`
`1086`		`-/* Scan pg_index to find indexes onheapRelation */`
	`1078`	`+/* Scan pg_index to find indexes onspecified heap */`
`1087`	`1079`	`indexRelation=heap_openr(IndexRelationName,AccessShareLock);`
`1088`	`1080`	`ScanKeyEntryInitialize(&entry,0,Anum_pg_index_indrelid,F_OIDEQ,`
`1089`	`1081`	`ObjectIdGetDatum(heapId));`
`1090`	`1082`	`scan=heap_beginscan(indexRelation, false,SnapshotNow,1,&entry);`
	`1083`	`+`
`1091`	`1084`	`while (HeapTupleIsValid(indexTuple=heap_getnext(scan,0)))`
`1092`	`1085`	`{`
	`1086`	`+OidindexId,`
	`1087`	`+accessMethodId;`
	`1088`	`+IndexInfo*indexInfo;`
	`1089`	`+HeapTupleclassTuple;`
	`1090`	`+RelationheapRelation,`
	`1091`	`+currentIndex;`
	`1092`	`+`
`1093`	`1093`	`/*`
`1094`	`1094`	`* For each index, fetch info needed for index_build`
`1095`	`1095`	`*/`
`@@ -1105,10 +1105,16 @@ RelationTruncateIndexes(Relation heapRelation)`
`1105`	`1105`	`indexId);`
`1106`	`1106`	`accessMethodId= ((Form_pg_class)GETSTRUCT(classTuple))->relam;`
`1107`	`1107`
	`1108`	`+/*`
	`1109`	`+ * We have to re-open the heap rel each time through this loop`
	`1110`	`+ * because index_build will close it again. We need grab no lock,`
	`1111`	`+ * however, because we assume heap_truncate is holding an exclusive`
	`1112`	`+ * lock on the heap rel.`
	`1113`	`+ */`
	`1114`	`+heapRelation=heap_open(heapId,NoLock);`
	`1115`	`+`
`1108`	`1116`	`/* Open the index relation */`
`1109`	`1117`	`currentIndex=index_open(indexId);`
`1110`		`-if (currentIndex==NULL)`
`1111`		`-elog(ERROR,"RelationTruncateIndexes: can't open index relation");`
`1112`	`1118`
`1113`	`1119`	`/* Obtain exclusive lock on it, just to be sure */`
`1114`	`1120`	`LockRelation(currentIndex,AccessExclusiveLock);`
`@@ -1127,15 +1133,10 @@ RelationTruncateIndexes(Relation heapRelation)`
`1127`	`1133`	`InitIndexStrategy(indexInfo->ii_NumIndexAttrs,`
`1128`	`1134`	`currentIndex,accessMethodId);`
`1129`	`1135`	`index_build(heapRelation,currentIndex,indexInfo,NULL);`
`1130`		`-`
`1131`	`1136`	`/*`
`1132`	`1137`	`* index_build will close both the heap and index relations (but`
`1133`		`- * not give up the locks we hold on them).That's fine for the`
`1134`		`- * index, but we need to open the heap again. We need no new`
`1135`		`- * lock, since this backend still has the exclusive lock grabbed`
`1136`		`- * by heap_truncate.`
	`1138`	`+ * not give up the locks we hold on them).`
`1137`	`1139`	`*/`
`1138`		`-heapRelation=heap_open(heapId,NoLock);`
`1139`	`1140`	`}`
`1140`	`1141`
`1141`	`1142`	`/* Complete the scan and close pg_index */`
`@@ -1191,17 +1192,12 @@ heap_truncate(char *relname)`
`1191`	`1192`	`rel->rd_nblocks=0;`
`1192`	`1193`
`1193`	`1194`	`/* If this relation has indexes, truncate the indexes too */`
`1194`		`-RelationTruncateIndexes(rel);`
	`1195`	`+RelationTruncateIndexes(rid);`
`1195`	`1196`
`1196`	`1197`	`/*`
`1197`	`1198`	`* Close the relation, but keep exclusive lock on it until commit.`
`1198`	`1199`	`*/`
`1199`	`1200`	`heap_close(rel,NoLock);`
`1200`		`-`
`1201`		`-/*`
`1202`		`- * Is this really necessary?`
`1203`		`- */`
`1204`		`-RelationForgetRelation(rid);`
`1205`	`1201`	`}`
`1206`	`1202`
`1207`	`1203`

0 commit comments

Comments

(0)

Movatterモバイル変換

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Commit36786a8

File tree

1 file changed

1 file changed

`‎src/backend/catalog/heap.c`

0 commit comments