Fix: typos (#4523)

* Fix: typos

Author: omahs

README.md

@@ -58,7 +58,7 @@ the connection string, check the [Postgres
 documentation](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING).
 `graph-node` uses a few Postgres extensions. If the Postgres user with which
 you run `graph-node` is a superuser, `graph-node` will enable these
-extensions when it initalizes the database. If the Postgres user is not a
+extensions when it initializes the database. If the Postgres user is not a
 superuser, you will need to create the extensions manually since only
 superusers are allowed to do that. To create them you need to connect as a
 superuser, which in many installations is the `postgres` user:

docs/getting-started.md

@@ -62,7 +62,7 @@ Below, we outline the required steps to build a subgraph from scratch, which wil
 
     2. [Create the Postgres database](#22-create-the-postgres-db)
 
-    3. [Start the Graph Node and Connect to an Etheruem node](#23-starting-the-graph-node-and-connecting-to-an-etheruem-node)
+    3. [Start the Graph Node and Connect to an Ethereum node](#23-starting-the-graph-node-and-connecting-to-an-ethereum-node)
 
     4. [Deploy the subgraph](#24-deploying-the-subgraph)
 3. Query the subgraph

docs/graphman.md

@@ -52,7 +52,7 @@ By default, it shows the following attributes for the deployment:
 -   **name**
 -   **status** *(`pending` or `current`)*
 -   **id** *(the `Qm...` identifier for the deployment's subgraph)*
--   **namespace** *(The database schema which contain's that deployment data tables)*
+-   **namespace** *(The database schema which contains that deployment data tables)*
 -   **shard**
 -   **active** *(If there are multiple entries for the same subgraph, only one of them will be active. That's the one we use for querying)*
 -   **chain**
@@ -169,7 +169,7 @@ primary shard.
 
 No indexed data is lost as a result of this command.
 
-This sub-command is used as previus step towards removing all data from unused subgraphs, followed by
+This sub-command is used as previous step towards removing all data from unused subgraphs, followed by
 `graphman unused remove`.
 
 A deployment is unused if it fulfills all of these criteria:
@@ -236,7 +236,7 @@ Remove a specific unused deployment
 
 ### SYNOPSIS
 
-    Delete a deployment and all it's indexed data
+    Delete a deployment and all its indexed data
 
     The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database
     namespace `sgdNNN`. Since the same IPFS hash can be deployed in multiple shards, it is possible to
@@ -322,7 +322,7 @@ is useful to diagnose the integrity of cached blocks and eventually fix them.
 
 ### OPTIONS
 
-Blocks can be selected by different methods. The `check-blocks` command let's you use the block hash, a single
+Blocks can be selected by different methods. The `check-blocks` command lets you use the block hash, a single
 number or a number range to refer to which blocks it should verify:
 
 #### `by-hash`
@@ -338,7 +338,7 @@ number or a number range to refer to which blocks it should verify:
     graphman --config <config> chain check-blocks <chain-name> by-range [-f|--from <block-number>] [-t|--to <block-number>] [--delete-duplicates]
 
 The `by-range` method lets you scan for numeric block ranges and offers the `--from` and `--to` options for
-you to define the search bounds. If one of those options is ommited, `graphman` will consider an open bound
+you to define the search bounds. If one of those options is omitted, `graphman` will consider an open bound
 and will scan all blocks up to or after that number.
 
 Over time, it can happen that a JSON RPC provider offers different blocks for the same block number. In those

docs/metrics.md

@@ -27,7 +27,7 @@ Track the **last reverted block** for a subgraph deployment
 - `deployment_sync_secs`
 total **time spent syncing**
 - `deployment_transact_block_operations_duration`
-Measures **duration of commiting all the entity operations** in a block and **updating the subgraph pointer**
+Measures **duration of committing all the entity operations** in a block and **updating the subgraph pointer**
 - `deployment_trigger_processing_duration`
 Measures **duration of trigger processing** for a subgraph deployment
 - `eth_rpc_errors`