Merge branch 'latest' into latest-fix-config

_partials/_usage-based-storage-intro.md

@@ -1,4 +1,4 @@
-Timescale charges are based on how much storage you use. You don't pay for a 
+$CLOUD_LONG charges are based on the amount of storage you use. You don't pay for 
 fixed storage size, and you don't need to worry about scaling disk size as your 
 data grows; We handle it all for you. To reduce your data costs further, 
 use [compression][compression], a [data retention policy][data-retention], and

self-hosted/upgrades/upgrade-pg.md

@@ -16,7 +16,20 @@ TimescaleDB is a PostgreSQL extension. Ensure that you upgrade to compatible ver
 <ConsiderCloud />
 
 
-## Prerequisites
+||PostgreSQL&nbsp;17|PostgreSQL&nbsp;16|PostgreSQL&nbsp;15|PostgreSQL&nbsp;14|PostgreSQL&nbsp;13|PostgreSQL&nbsp;12|PostgreSQL&nbsp;11|PostgreSQL&nbsp;10|PostgreSQL&nbsp;9.6|
+|-|-|-|-|-|-|-|-|-|
+|TimescaleDB&nbsp;2.17 and higher|&#9989;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.16 and higher|&#10060;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.15 and higher|&#10060;|&#9989;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.14 and higher|&#10060;|&#9989;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.13 and higher|&#10060;|&#9989;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.12 and higher|&#10060;|&#10060;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.10 and higher|&#10060;|&#10060;|&#9989;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.5 to 2.9|&#10060;|&#10060;|&#10060;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.4|&#10060;|&#10060;|&#10060;|&#10060;|&#9989;|&#9989;|&#10060;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.1 to 2.3|&#10060;|&#10060;|&#10060;|&#10060;|&#9989;|&#9989;|&#9989;|&#10060;|&#10060;|
+|TimescaleDB&nbsp;2.0|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|&#9989;|&#9989;|&#10060;|&#10060;
+|TimescaleDB&nbsp;1.7|&#10060;|&#10060;|&#10060;|&#10060;|&#10060;|&#9989;|&#9989;|&#9989;|&#9989;|
 
 <PlanUpgrade />
 

use-timescale/services/change-resources.md

@@ -11,84 +11,87 @@ cloud_ui:
 
 import UsageBasedStorage from "versionContent/_partials/_usage-based-storage-intro.mdx";
 
-# Resources
+# Manually change compute resources
 
 <UsageBasedStorage />
 
-Timescale allows you to resize compute (CPU/RAM) resources independently at any
-time. You can resize compute in the Timescale console for any service, with a
-short downtime.
+You use [$CONSOLE][cloud-login] to resize the compute (CPU/RAM) resources available to your
+$SERVICE_LONGs at any time, with a short downtime.
 
-Because compute changes require an interruption to your service, plan
-accordingly so that the settings are applied during an appropriate service
-window.
+## Update compute resources for a $SERVICE_LONG
 
-## Compute resources
+You can change the CPU and memory allocation for your $SERVICE_LONG at any time with
+minimal downtime, usually less than a minute. The new resources become available as soon as 
+the service restarts. You can change the CPU and memory allocation up or down, as frequently as required. 
 
-You can change the CPU and memory allocation for your service at any time, with
-minimal downtime, usually less than thirty seconds. The new resources become
-available as soon as the service restarts. You can change the CPU and memory
-allocation up or down, as frequently as required.
+![Change resources](https://assets.timescale.com/docs/images/console-update-resources.png)
 
-There is momentary downtime while the new compute settings are applied. In most
-cases, this downtime is less than 30 seconds.
+There is momentary downtime while the new compute settings are applied. In most cases, this is 
+less than a minute. However, Before making changes to your service, best practice
+is to enable [HA replication][high-availability] on the service. When you resize a service with HA enabled,
+$CLOUD_LONG:
+
+1. Resizes the replica.
+1. Waits for the replica to catch up.
+1. Performs a switchover to the resized replica.
+1. Restarts the primary.
+
+HA reduce downtime in the case of resizes or maintenance window restarts, from a minute or so to a couple of seconds.
 
 When you change resource settings, the current and new charges are displayed
 immediately so that you can verify how the changes impact your costs.
 
 <Highlight type="warning">
-Changing your compute settings usually requires a short downtime. Make sure you
-plan for this before you begin.
-</Highlight>
 
-<Procedure>
+Because compute changes require an interruption to your $SERVICE_LONGs, plan accordingly so that the
+settings are applied during an appropriate service window.
 
-### Changing resource allocations manually
+</Highlight>
 
-1.  In the Timescale console, from the `Services` list, click the name of
-    the service you want to modify.
-1.  In the `Service details` page, navigate to the `Operations` tab, and click
-    `Compute`.
-1.  In the `Change CPU/Memory` field, select the new CPU and memory
-    allocation.
-1.  Review the new allocations and costs in the comparison chart.
-1.  Click `Apply` to save your changes. Your service goes down briefly while the
-    changes are applied.
+<Procedure>
 
-    <img class="main-content__illustration"
-    src="https://assets.timescale.com/docs/images/tsc-resources-changed.webp"
-    width={1375} height={944}
-    alt="Changing Timescale service compute size" />
+1. In [$CONSOLE][services-portal], choose the $SERVICE_SHORT to modify.
+1. Click `Operations`, then click `Compute`.
+1. Select the new `CPU / Memory` allocation.
+    You see the allocation and costs in the comparison chart
+1. Click `Apply`. 
+    Your service goes down briefly while the changes are applied.
 
 </Procedure>
 
 ## Out of memory errors
 
-If you run intensive queries on your Timescale services, you might
+If you run intensive queries on your $SERVICE_LONGs, you might
 encounter out of memory (OOM) errors. This occurs if your query consumes more
 memory than is available.
 
 When this happens, an `OOM killer` process shuts down PostgreSQL processes using
-`SIGKILL` commands, until the memory usage falls below the upper limit. Because
-this kills the entire server process, it usually requires a restart. To
-prevent service disruption caused by OOM errors, Timescale attempts to
+`SIGKILL` commands until the memory usage falls below the upper limit. Because
+this kills the entire server process, it usually requires a restart. 
+
+To prevent service disruption caused by OOM errors, $CLOUD_LONG attempts to
 shut down only the query that caused the problem. This means that the
-problematic query does not run, but that your PostgreSQL service continues to
+problematic query does not run, but that your $SERVICE_LONG continues to
 operate normally.
 
-If the normal OOM killer is triggered, the error log looks like this:
+* If the normal OOM killer is triggered, the error log looks like this:
 
-```yml
-2021-09-09 18:15:08 UTC [560567]:TimescaleDB: LOG: server process (PID 2351983) was terminated by signal 9: Killed
-```
+   ```yml
+   2021-09-09 18:15:08 UTC [560567]:TimescaleDB: LOG: server process (PID 2351983) was terminated by signal 9: Killed
+   ```
+   
+   Wait for the $SERVICE_LONG to come back online before reconnecting.
 
-Wait for the entire service to come back online before reconnecting.
+* $CLOUD_LONG shuts the client connection only 
+  
+  If $CLOUD_LONG successfully guards the $SERVICE_SHORT against the OOM killer, it shuts
+  down only the client connection that was using too much memory. This prevents
+  the entire $SERVICE_LONG from shutting down, so you can reconnect immediately. The error log looks like this:
 
-If Timescale successfully guards the service against the OOM killer, it shuts
-down only the client connection that was using too much memory. This prevents
-the entire PostgreSQL service from shutting down, so you can reconnect
-immediately. The error log looks like this:
+   ```yml
+   2022-02-03 17:12:04 UTC [2253150]:TimescaleDB: tsdbadmin@tsdb,app=psql [53200] ERROR: out of memory
+   ```
 
-```yml
-2022-02-03 17:12:04 UTC [2253150]:TimescaleDB: tsdbadmin@tsdb,app=psql [53200] ERROR: out of memory
-```
+[cloud-login]: https://console.cloud.timescale.com/
+[high-availability]: /use-timescale/:currentVersion:/ha-replicas/high-availability/
+[services-portal]: https://console.cloud.timescale.com/dashboard/services