Merge branch 'latest' into 3292-docs-rfc-update-docs-to-remove-centos-have-correct-versions-of-postgres-support-and-align-supported-platforms

Author: atovpeko

.helper-scripts/llms/generate_llms_full.py

@@ -17,5 +17,5 @@ Is converted and compressed into arrays in a row in the columnstore:
 |-|-|-|-|-|
 |[12:00:01, 12:00:01, 12:00:02, 12:00:02, 12:00:03, 12:00:03]|[A, B, A, B, A, B]|[SSD, HDD, SSD, HDD, SSD, HDD]|[70.11, 69.70, 70.12, 69.69, 70.14, 69.70]|[13.4, 20.5, 13.2, 23.4, 13.0, 25.2]|
 
-Because a single row takes up less disk space, you can reduce your chunk size by more than 90%, and can also
+Because a single row takes up less disk space, you can reduce your chunk size by up to 98%, and can also
 speed up your queries. This saves on storage costs, and keeps your queries operating at lightning speed.

_partials/_hypercore-conversion-overview.md

@@ -21,7 +21,7 @@ $HYPERCORE_CAP’s hybrid approach combines the benefits of row-oriented and col
   saving significant storage space.
 
 - **Faster queries on compressed data in $COLUMNSTORE**: in the $COLUMNSTORE conversion, hypertable
-  chunks are compressed by more than 90%, and organized for efficient, large-scale queries. Combined with [chunk skipping][chunk-skipping], this helps you save on storage costs and keeps your queries operating at lightning speed.
+  chunks are compressed by up to 98%, and organized for efficient, large-scale queries. Combined with [chunk skipping][chunk-skipping], this helps you save on storage costs and keeps your queries operating at lightning speed.
 
 - **Fast modification of compressed data in $COLUMNSTORE**: just use SQL to add or modify data in the $COLUMNSTORE.
    $TIMESCALE_DB is optimized for super fast INSERT and UPSERT performance.  

_partials/_hypercore-intro.md

@@ -23,59 +23,59 @@ Updating parameters on a $PG instance will cause an outage. Choose a time that w
       - `rds.logical_replication` set to `1`: record the information needed for logical decoding.
       - `wal_sender_timeout` set to `0`: disable the timeout for the sender process.
 
-   1. In RDS, navigate back to your [databases][databases], select the RDS instance to migrate and click `Modify`.  
+   1. In RDS, navigate back to your [databases][databases], select the RDS instance to migrate, and click `Modify`.  
 
-   1. Scroll down to `Database options` select your new parameter group and click `Continue`. 
-   1. Either `Apply immediately` or choose a maintence window, then click `Modify DB instance`.
+   1. Scroll down to `Database options`, select your new parameter group, and click `Continue`. 
+   1. Click `Apply immediately` or choose a maintenance window, then click `Modify DB instance`.
 
       Changing parameters will cause an outage. Wait for the database instance to reboot before continuing. 
    1. Verify that the settings are live in your database.
 
-1. **Create a user for $LIVESYNC and assign permissions**
+1. **Create a user for the $PG_CONNECTOR and assign permissions**
 
-   1. Create `<livesync username>`:
+   1. Create `<pg connector username>`:
 
       ```sql
-      psql $SOURCE -c "CREATE USER <livesync username> PASSWORD '<password>'"
+      psql $SOURCE -c "CREATE USER <pg connector username> PASSWORD '<password>'"
       ```
 
       You can use an existing user. However, you must ensure that the user has the following permissions.
 
    1. Grant permissions to create a replication slot:
 
       ```sql
-      psql $SOURCE -c "GRANT rds_replication TO <livesync username>"
+      psql $SOURCE -c "GRANT rds_replication TO <pg connector username>"
       ```
 
    1. Grant permissions to create a publication:
 
       ```sql
-      psql $SOURCE -c "GRANT CREATE ON DATABASE <database name> TO <livesync username>"
+      psql $SOURCE -c "GRANT CREATE ON DATABASE <database name> TO <pg connector username>"
       ```
 
    1. Assign the user permissions on the source database:
 
       ```sql
       psql $SOURCE <<EOF
-      GRANT USAGE ON SCHEMA "public" TO <livesync username>;
-      GRANT SELECT ON ALL TABLES IN SCHEMA "public" TO <livesync username>;
-      ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO <livesync username>;
+      GRANT USAGE ON SCHEMA "public" TO <pg connector username>;
+      GRANT SELECT ON ALL TABLES IN SCHEMA "public" TO <pg connector username>;
+      ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO <pg connector username>;
       EOF
       ```
 
       If the tables you are syncing are not in the `public` schema, grant the user permissions for each schema you are syncing:
       ```sql
       psql $SOURCE <<EOF
-      GRANT USAGE ON SCHEMA <schema> TO <livesync username>;
-      GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <livesync username>;
-      ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <livesync username>;
+      GRANT USAGE ON SCHEMA <schema> TO <pg connector username>;
+      GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <pg connector username>;
+      ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <pg connector username>;
       EOF
       ```
 
-   1. On each table you want to sync, make `<livesync username>` the owner:
+   1. On each table you want to sync, make `<pg connector username>` the owner:
 
       ```sql
-      psql $SOURCE -c 'ALTER TABLE <table name> OWNER TO <livesync username>;'
+      psql $SOURCE -c 'ALTER TABLE <table name> OWNER TO <pg connector username>;'
       ```
       You can skip this step if the replicating user is already the owner of the tables.
 

_partials/_livesync-configure-source-database-awsrds.md

@@ -9,57 +9,57 @@ import EnableReplication from "versionContent/_partials/_migrate_live_setup_enab
    ALTER SYSTEM SET wal_sender_timeout=0;
    EOF
    ```
-   * [ GUC “wal_level” as “logical”](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-LEVEL)
+   * [GUC “wal_level” as “logical”](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-LEVEL)
    * [GUC “max_wal_senders” as 10](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-MAX-WAL-SENDERS)
    * [GUC “wal_sender_timeout” as 0](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-SENDER-TIMEOUT)
 
    This will require a restart of the $PG source database.
 
-1. **Create a user for $LIVESYNC and assign permissions**
+1. **Create a user for the connector and assign permissions**
 
-   1. Create `<livesync username>`:
+   1. Create `<pg connector username>`:
 
       ```sql
-      psql $SOURCE -c "CREATE USER <livesync username> PASSWORD '<password>'"
+      psql $SOURCE -c "CREATE USER <pg connector username> PASSWORD '<password>'"
       ```
 
       You can use an existing user. However, you must ensure that the user has the following permissions.
 
    1. Grant permissions to create a replication slot:
 
       ```sql
-      psql $SOURCE -c "ALTER ROLE <livesync username> REPLICATION"
+      psql $SOURCE -c "ALTER ROLE <pg connector username> REPLICATION"
       ```
 
    1. Grant permissions to create a publication:
 
       ```sql
-      psql $SOURCE -c "GRANT CREATE ON DATABASE <database name> TO <livesync username>"
+      psql $SOURCE -c "GRANT CREATE ON DATABASE <database name> TO <pg connector username>"
       ```
 
    1. Assign the user permissions on the source database:
 
       ```sql
       psql $SOURCE <<EOF
-      GRANT USAGE ON SCHEMA "public" TO <livesync username>;
-      GRANT SELECT ON ALL TABLES IN SCHEMA "public" TO <livesync username>;
-      ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO <livesync username>;
+      GRANT USAGE ON SCHEMA "public" TO <pg connector username>;
+      GRANT SELECT ON ALL TABLES IN SCHEMA "public" TO <pg connector username>;
+      ALTER DEFAULT PRIVILEGES IN SCHEMA "public" GRANT SELECT ON TABLES TO <pg connector username>;
       EOF
       ```
 
       If the tables you are syncing are not in the `public` schema, grant the user permissions for each schema you are syncing:
       ```sql
       psql $SOURCE <<EOF
-      GRANT USAGE ON SCHEMA <schema> TO <livesync username>;
-      GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <livesync username>;
-      ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <livesync username>;
+      GRANT USAGE ON SCHEMA <schema> TO <pg connector username>;
+      GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <pg connector username>;
+      ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <pg connector username>;
       EOF
       ```
 
-   1. On each table you want to sync, make `<livesync username>` the owner:
+   1. On each table you want to sync, make `<pg connector username>` the owner:
 
       ```sql
-      psql $SOURCE -c 'ALTER TABLE <table name> OWNER TO <livesync username>;'
+      psql $SOURCE -c 'ALTER TABLE <table name> OWNER TO <pg connector username>;'
       ```
       You can skip this step if the replicating user is already the owner of the tables.
 

_partials/_livesync-configure-source-database.md

@@ -11,7 +11,7 @@ import TuneSourceDatabaseAWSRDS from "versionContent/_partials/_livesync-configu
 
 - Ensure that the source $PG instance and the target $SERVICE_LONG have the same extensions installed.
 
-  $LIVESYNC_CAP does not create extensions on the target. If the table uses column types from an extension,
+  The $PG_CONNECTOR does not create extensions on the target. If the table uses column types from an extension,
     first create the extension on the target $SERVICE_LONG before syncing the table.
 
 ## Limitations
@@ -28,18 +28,19 @@ import TuneSourceDatabaseAWSRDS from "versionContent/_partials/_livesync-configu
 
 ## Set your connection string
 
-This variable holds the connection information for the source database. In Terminal on your migration machine, 
+This variable holds the connection information for the source database. In the terminal on your migration machine, 
 set the following:
 
 ```bash
 export SOURCE="postgres://<user>:<password>@<source host>:<source port>/<db_name>"
 ```
 
 <Highlight type="important">
+
 Avoid using connection strings that route through connection poolers like PgBouncer or similar tools. This tool 
 requires a direct connection to the database to function properly.
-</Highlight>
 
+</Highlight>
 
 ## Tune your source database
 
@@ -65,7 +66,7 @@ requires a direct connection to the database to function properly.
 </Tab>
 </Tabs>
 
-## Synchronize data to your Tiger Cloud service
+## Synchronize data to your $SERVICE_LONG
 
 To sync data from your $PG database to your $SERVICE_LONG using $CONSOLE:
 
@@ -74,40 +75,51 @@ To sync data from your $PG database to your $SERVICE_LONG using $CONSOLE:
 1. **Connect to your $SERVICE_LONG**
 
    In [$CONSOLE][portal-ops-mode], select the $SERVICE_SHORT to sync live data to. 
-1. **Start $LIVESYNC**
-   1. Click `Actions` > `Livesync for PostgreSQL`.
 
-1. **Connect the source database and target $SERVICE_SHORT**
+1. **Connect the source database and the target $SERVICE_SHORT**
 
-   ![Livesync wizard](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-livesync-wizard-tiger-cloud.png)
+   ![Postgres connector wizard](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-connector-wizard-tiger-cloud.png)
 
-   In `Livesync for Postgres`:
-   1. Set the `Livesync Name`.
-   1. Connect to your database with the credentials or $PG connection string. This is the connection string for [`<livesync username>`][livesync-tune-source-db]. 
-   1. Click `Continue`.
-      $CONSOLE connects to the source database and retrieves the schema information.
+   1. Click `Connectors` > `PostgreSQL`.
+   1. Set the name for the new connector by clicking the pencil icon.
+   1. Check the boxes for `Set wal_level to logical` and `Update your credentials`, then click `Continue`.
+   1. Enter your database credentials or a $PG connection string, then click `Connect to database`. 
+      This is the connection string for [`<pg connector username>`][livesync-tune-source-db]. $CONSOLE connects to the source database and retrieves the schema information.
 
-1. **Optimize the data to synchronize in hypertables**
+1. **Optimize the data to synchronize in $HYPERTABLEs**
 
-   ![livesync start](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-livesync-start-tiger-cloud.png)
-   1. Select the table to sync and click `+`.
+   ![Postgres connector start](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-connector-start-tiger-cloud.png)
+
+   1. In the `Select table` dropdown, select the tables to sync.
+   1. Click `Select tables +` .    
+
+      $CONSOLE checks the table schema and, if possible, suggests the column to use as the time dimension in a $HYPERTABLE.
+   1. Click `Create Connector`.
 
-      $CONSOLE checks the table schema and, if possible, suggests the column to use as the time dimension in a hypertable. 
-   1. Repeat this step for each table you want to sync.
-   1. Click `Start Livesync`.
+      $CONSOLE starts $PG_CONNECTOR between the source database and the target $SERVICE_SHORT and displays the progress.
+
+1. **Monitor synchronization**
+
+   ![Tiger Cloud connectors overview](https://assets.timescale.com/docs/images/tiger-cloud-console/tiger-cloud-connector-overview.png)
+
+    1. To view the amount of data replicated, click `Connectors`. The diagram in `Connector data flow` gives you an overview of the connectors you have created, their status, and how much data has been replicated.  
+
+    1. To review the syncing progress for each table, click `Connectors` > `Source connectors`, then select the name of your connector in the table. 
+
+1. **Manage the connector**
+
+   ![Edit a Postgres connector](https://assets.timescale.com/docs/images/tiger-cloud-console/edit-pg-connector.png)
+
+   1. To edit the connector, click `Connectors` > `Source connectors`, then select the name of your connector in the table. You can rename the connector, delete or add new tables for syncing.
 
-      $CONSOLE starts $LIVESYNC between the source database and the target $SERVICE_SHORT and displays the progress.
+   1. To pause a connector, click `Connectors` > `Source connectors`, then open the three-dot menu on the right and select `Pause`. 
 
-1. **Monitor syncronization**
-   1. To view the progress of the $LIVESYNC, click the name of the $LIVESYNC process:
-      ![livesync view status](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-livesync-view-status-tiger-cloud.png)
-   1. To pause and restart $LIVESYNC, click the buttons on the right of the $LIVESYNC process and select an action:
-      ![livesync start stop](https://assets.timescale.com/docs/images/tiger-cloud-console/pg-livesync-start-stop-tiger-cloud.png)
+   1. To delete a connector, click `Connectors` > `Source connectors`, then open the three-dot menu on the right and select `Delete`. You must pause the connector before deleting it.
 
 </Procedure>
 
-And that is it, you are using $LIVESYNC to synchronize all the data, or specific tables, from a $PG database 
-instance to your $SERVICE_LONG in real time.
+And that is it, you are using the $PG_CONNECTOR to synchronize all the data, or specific tables, from a $PG database 
+instance to your $SERVICE_LONG, in real time.
 
 [install-psql]: /integrations/:currentVersion:/psql/
 [portal-ops-mode]: https://console.cloud.timescale.com/dashboard/services

_partials/_livesync-console.md

@@ -9,15 +9,15 @@
 
 * Ensure that the source $PG instance and the target $SERVICE_LONG have the same extensions installed.
 
-  $LIVESYNC_CAP does not create extensions on the target. If the table uses
+  The $PG_CONNECTOR does not create extensions on the target. If the table uses
   column types from an extension, first create the extension on the
   target $SERVICE_LONG before syncing the table.
 
 * There is WAL volume growth on the source $PG instance during large table copy.
 
-* Continuous Aggregates Invalidation
+* Continuous aggregate invalidation
 
-  LiveSync uses `session_replication_role=replica` during data replication,
+  The connector uses `session_replication_role=replica` during data replication,
   which prevents table triggers from firing. This includes the internal
   triggers that mark continuous aggregates as invalid when underlying data
   changes.
@@ -35,7 +35,7 @@
   - Queries returning incomplete results.
 
   If the continuous aggregate exists in the source database, best
-  practice is to add it to the live-sync publication. If it only exists on the
+  practice is to add it to the $PG connector publication. If it only exists on the
   target database, manually refresh the continuous aggregate using the `force`
   option of [refresh_continuous_aggregate][refresh-caggs].