Fix small typos in release notes

Author: cbandy

docs/content/releases/5.1.0.md

@@ -24,15 +24,15 @@ Read more about how you can [get started]({{< relref "quickstart/_index.md" >}})
 
 ### pgAdmin 4 Integration
 
-PGO v5.1 reintroduces the pgAdmin 4 integration from [PGO v4](https://access.crunchydata.com/documentation/postgres-operator/4.7.5/architecture/pgadmin4/). v5.1 adds the [`spec.userInterace.pgadmin`]({{< relref "references/crd.md" >}}#postgresclusterspecuserinterfacepgadmin) section to the `PostgresCluster` custom resource to enable pgAdmin 4 integration for a Postgres cluster. Any users defined in `spec.users` are are synced with pgAdmin 4, allowing for a seamless management experience.
+PGO v5.1 reintroduces the pgAdmin 4 integration from [PGO v4](https://access.crunchydata.com/documentation/postgres-operator/4.7.5/architecture/pgadmin4/). v5.1 adds the [`spec.userInterace.pgAdmin`]({{< relref "references/crd.md" >}}#postgresclusterspecuserinterfacepgadmin) section to the `PostgresCluster` custom resource to enable pgAdmin 4 integration for a Postgres cluster. Any users defined in `spec.users` are are synced with pgAdmin 4, allowing for a seamless management experience.
 
 Please see the [pgAdmin 4 section](https://access.crunchydata.com/documentation/postgres-operator/v5/architecture/pgadmin4/) of the PGO documentation for more information about this integration.
 
 ### Removal of SSH Requirement for Local Backups
 
 Previous versions of PGO relied on the use of `ssh` to take backups and store archive files on Kubernetes-managed storage. PGO v5.1 now uses mTLS to securely transfer and manage these files.
 
-The upgrade to pgBackRest TLS is seamless and transparent if using related image environment variables with your PGO Deployment (please see the [PostgresCluster CRD reference](https://access.crunchydata.com/documentation/postgres-operator/v5/references/crd/) for more information).  This is because PGO will automatically handle updating all image tags across all existing PostgreCluster's following the upgrade to v5.1, seamlessly rolling out any new images as required for proper pgBackRest TLS functionality.
+The upgrade to pgBackRest TLS is seamless and transparent if using related image environment variables with your PGO Deployment (please see the [PostgresCluster CRD reference](https://access.crunchydata.com/documentation/postgres-operator/v5/references/crd/) for more information).  This is because PGO will automatically handle updating all image tags across all existing PostgresCluster's following the upgrade to v5.1, seamlessly rolling out any new images as required for proper pgBackRest TLS functionality.
 
 If you are not using related image environment variables, and are instead explicitly defining images via the `image` fields in your PostgresCluster spec, then an additional step is required in order to ensure a seamless upgrade.  Specifically, all `postgrescluster.spec.image` and `postgrescluster.spec.backups.pgbackrest.image` fields must first be updated to specify images containing pgBackRest 2.38.  Therefore, prior to upgrading, please update all `postgrescluster.spec.image` and `postgrescluster.spec.backups.pgbackrest.image` fields to the latest versions of the `crunchy-postgres` and `crunchy-pgbackrest` containers available per the [Components and Compatibility guide](https://access.crunchydata.com/documentation/postgres-operator/v5/references/components/) (please note that the `crunchy-postgres` container should be updated to the latest version available for the major version of PostgreSQL currently being utilized within a cluster).
 
@@ -42,7 +42,7 @@ In the event that PGO is upgraded to v5.1 _before_ updating your image tags, sim
 
 - Set [Pod Disruption Budgets]({{< relref "architecture/high-availability.md" >}}#pod-disruption-budgets) (PDBs) for both Postgres and PgBouncer instances.
 - Postgres configuration changes requiring a database restart are now automatically rolled out to all instances in the cluster.
-- For rolling updates that do not require Pod recreation, e.g. applying a change that requires a database restart, PGO no longer recreates all of the database instance Pods. These types of changes are now applied more quickly.
+- Do not recreate instance Pods for changes that only require a Postgres restart. These types of changes are now applied more quickly.
 - Support for [manual switchovers or failovers]({{< relref "tutorial/administrative-tasks.md">}}#changing-the-primary).
 - Rotate PgBouncer TLS certificates without downtime.
 - Add support for using Active Directory for securely authenticating with PostgreSQL using the GSSAPI.
@@ -52,7 +52,7 @@ In the event that PGO is upgraded to v5.1 _before_ updating your image tags, sim
 
 ## Changes
 
-- As a result of [a fix in pgBouncer v1.16](https://github.com/libusual/libusual/commit/ab960074cb7a), PGO no longer sets verbosity settings in the PgBouncer configuration to catch missing `%include` directives.  Users can increase verbosity in their own configuration files to maintain the previous behavior.
+- As a result of [a fix in PgBouncer v1.16](https://github.com/libusual/libusual/commit/ab960074cb7a), PGO no longer sets verbosity settings in the PgBouncer configuration to catch missing `%include` directives.  Users can increase verbosity in their own configuration files to maintain the previous behavior.
 - The Postgres `archive_timeout` setting now defaults to 60 seconds (`60s`), which matches the behavior from PGO v4. If you do not require for WAL files to be generated once a minute (e.g. generally idle system where a window of data-loss is acceptable or a development system), you can set this to `0`:
 
 ```yaml
@@ -63,8 +63,8 @@ spec:
         parameters:
           archive_timeout: 0
 ```
-- All Pods now have `enableServiceLinks` set to `false` in order to ensure injected environment variables do not conflict with the various applications running within various PGO Pods.
+- All Pods now have `enableServiceLinks` set to `false` in order to ensure injected environment variables do not conflict with the various applications running within.
 
 ## Fixes
 
-- The name of the CronJob created for a scheduled backup has been shortened to `<cluster name>-<repo#>-<backup type>` to allow for longer PostgresCluster names.
+- The names of CronJobs created for scheduled backups are shortened to `<cluster name>-<repo#>-<backup type>` to allow for longer PostgresCluster names.