Fix more typos in comments.

Patch by CharSyam, plus a few more I spotted with grep.

src/backend/access/brin/brin_pageops.c

@@ -494,7 +494,7 @@ brin_evacuate_page(Relation idxRel, BlockNumber pagesPerRange,
  * index item of size itemsz.  If oldbuf is a valid buffer, it is also locked
  * (in an order determined to avoid deadlocks.)
  *
- * If there's no existing page with enough free space to accomodate the new
+ * If there's no existing page with enough free space to accommodate the new
  * item, the relation is extended.  If this happens, *extended is set to true.
  *
  * If we find that the old page is no longer a regular index page (because

src/backend/access/heap/README.tuplock

@@ -9,7 +9,7 @@ is implemented by storing locking information in the tuple header: a tuple is
 marked as locked by setting the current transaction's XID as its XMAX, and
 setting additional infomask bits to distinguish this case from the more normal
 case of having deleted the tuple.  When multiple transactions concurrently
-lock a tuple, a MultiXact is used; see below.  This mechanism can accomodate
+lock a tuple, a MultiXact is used; see below.  This mechanism can accommodate
 arbitrarily large numbers of tuples being locked simultaneously.
 
 When it is necessary to wait for a tuple-level lock to be released, the basic

src/backend/access/transam/twophase.c

@@ -269,7 +269,7 @@ AtAbort_Twophase(void)
 	 * can be finished later, so just unlock it.
 	 *
 	 * If we abort during prepare, after having written the WAL record, we
-	 * might not have transfered all locks and other state to the prepared
+	 * might not have transferred all locks and other state to the prepared
 	 * transaction yet.  Likewise, if we abort during commit or rollback,
 	 * after having written the WAL record, we might not have released
 	 * all the resources held by the transaction yet.  In those cases, the

src/backend/access/transam/xact.c

@@ -2317,7 +2317,7 @@ PrepareTransaction(void)
 	/*
 	 * In normal commit-processing, this is all non-critical post-transaction
 	 * cleanup.  When the transaction is prepared, however, it's important that
-	 * the locks and other per-backend resources are transfered to the
+	 * the locks and other per-backend resources are transferred to the
 	 * prepared transaction's PGPROC entry.  Note that if an error is raised
 	 * here, it's too late to abort the transaction. XXX: This probably should
 	 * be in a critical section, to force a PANIC if any of this fails, but