@@ -334,19 +334,20 @@ _hash_first(IndexScanDesc scan, ScanDirection dir)
334334 so -> hashso_bucket_buf = buf ;
335335
336336 /*
337- * If the bucket split is in progress, then while scanning the bucket
338- * being populated, we need to skip tuples that are moved from bucket
339- * being split. We need to maintain the pin on bucket being split to
337+ * If a bucket split is in progress, then while scanning the bucket being
338+ * populated, we need to skip tuples that were copied from bucket being
339+ * split. We also need to maintain a pin on the bucket being split to
340340 * ensure that split-cleanup work done by vacuum doesn't remove tuples
341- * from it till this scan is done. We need to main to maintain the pin on
341+ * from it till this scan is done. We need to maintain a pin on the
342342 * bucket being populated to ensure that vacuum doesn't squeeze that
343- * bucket till this scan is complete, otherwise the ordering of tuples
343+ * bucket till this scan is complete; otherwise, the ordering of tuples
344344 * can't be maintained during forward and backward scans. Here, we have
345- * to be cautious about locking order, first acquire the lock on bucket
346- * being split, release the lock on it, but not pin, then acquire the lock
347- * on bucket being populated and again re-verify whether the bucket split
348- * still is in progress. First acquiring lock on bucket being split
349- * ensures that the vacuum waits for this scan to finish.
345+ * to be cautious about locking order: first, acquire the lock on bucket
346+ * being split; then, release the lock on it but not the pin; then,
347+ * acquire a lock on bucket being populated and again re-verify whether
348+ * the bucket split is still in progress. Acquiring the lock on bucket
349+ * being split first ensures that the vacuum waits for this scan to
350+ * finish.
350351 */
351352 if (H_BUCKET_BEING_POPULATED (opaque ))
352353 {
0 commit comments