1. In the AWS console, find the parameter group of the instance. If it uses a default parameter group, create a custom parameter group and apply it to the instance first. On Aurora, apply the parameter group to the instance, not the cluster.

2. In the custom parameter group, set these parameters:

   shared_preload_libraries = 'pg_stat_statements,auto_explain'
   logging_collector = on
   log_destination = 'csvlog'

3. Save the changes

1. In the Azure portal, open the Flexible Server. In the Settings section, click Server parameters.

2. Search for each parameter and set its value:
   

   shared_preload_libraries = 'pg_stat_statements,auto_explain'
   logging_collector = on
   log_destination = 'csvlog'

3. Click Save. If a change needs a restart, Azure restarts the server when you save.

1. In the Google Cloud console, open the Cloud SQL instance and click Edit.

2. Expand Flags and parameters, and add this flag:

    cloudsql.enable_auto_explain = on

3. Click Save. Cloud SQL restarts the instance to apply the flag.

1. In the Google Cloud console, go to the AlloyDB Clusters page and click the cluster.

2. In Instances in your cluster, click Edit for the primary instance.

3. Expand Show advanced options, click Add flag, and add this flag:

    alloydb.enable_auto_explain = on

4. Click Update instance. AlloyDB restarts the instance to apply the flag.

Connect to the host and restart the PostgreSQL Windows service. Do one of the following:

• Open Services (services.msc), right-click the PostgreSQL service (for example postgresql-x64-17), and choose Restart.
• In an elevated PowerShell session, run the following, replacing 17 with your PostgreSQL major version: 

  Restart-Service postgresql-x64-17

1. In the AWS console, navigate to the RDS service, ensuring you are viewing the correct AWS region.
2. In the left-hand navigation, select the Database menu item to display a list of instances.
3. Select the instance you wish to restart.
4. Click the Actions menu item, and choose Reboot.

Note that for Amazon Aurora, each instance in the cluster must be rebooted.

More guidance on rebooting approaches for Amazon Aurora is available here.

1. In the Azure portal, navigate to the list of Flexible Servers for PostgreSQL.
2. Select the instance you wish to restart.
3. In the actions bar at the top of the overview page, click "Restart".

Restart the Cloud SQL instance with either of the methods below.

1. In the Google Cloud console, navigate to the list of Cloud SQL instances, ensuring you have the correct project selected.
2. Select the instance you wish to restart.
3. In the actions bar at the top of the overview page, click "Restart", and confirm.

Alternatively, restart the instance with the gcloud CLI, replacing the INSTANCE_NAME and PROJECT_ID parameters:

gcloud sql instances restart INSTANCE_NAME --project=PROJECT_ID

Restart the AlloyDB primary instance with either of the methods below.

1. In the Google Cloud console, go to the AlloyDB Clusters page, ensuring you have the correct project selected.

2. Click the cluster that contains the instance.

3. On the Overview page, in the Instances in your cluster section, choose the primary instance, and click Restart.

Alternatively, restart the instance with the gcloud CLI, replacing the INSTANCE_ID, CLUSTER_ID, REGION_ID and PROJECT_ID parameters:

gcloud alloydb instances restart INSTANCE_ID \
    --cluster=CLUSTER_ID \
    --region=REGION_ID \
    --project=PROJECT_ID

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
GRANT ALL PRIVILEGES ON SCHEMA public TO redgatemonitor;

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS log_fdw;
CREATE SERVER sqlmonitor_file_server FOREIGN DATA WRAPPER log_fdw;
GRANT EXECUTE ON FUNCTION list_postgres_log_files() TO redgatemonitor;
GRANT EXECUTE ON FUNCTION create_foreign_table_for_log_file(text, text, text) TO redgatemonitor;
GRANT USAGE ON FOREIGN SERVER sqlmonitor_file_server TO redgatemonitor;
GRANT ALL PRIVILEGES ON SCHEMA public TO redgatemonitor;

Before running the SQL below to create the pg_stat_statements extension, you will need to add the extension to the server's allow list by following Microsoft's documentation.

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

1. In the Azure portal, enable server logs for your PostgreSQL Flexible Server instance.
   1. Using the Azure portal, under the Monitoring section of your instance page in the Azure portal, select Server logs and mark the Capture logs for download checkbox. Then press Save.
      
   2. Alternatively, you can run the following Azure CLI command, replacing the resource_group and server parameters.

   az postgres flexible-server parameter set \
     --resource-group <resource_group> \
     --server-name <server> \
     --name logfiles.download_enable \
     --value on

2. On the left hand navigation, select the Settings > Server parameters page.
3. Change the value of the log_line_prefix parameter to: %c<||>%l<||>%n<||>%u<||>%d<||>%p<||>%i<||>%v<||>%x<||>%e<||>%a<||>%b<||>%q<||>

In the "redgatemonitor" utility database, create the pg_stat_statements extension:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

To enable host monitoring, provide Redgate Monitor with a Google Cloud service account key (JSON). Grant the service account the following IAM roles on the project that contains the Cloud SQL instance:

• roles/cloudsql.viewer – to discover the Cloud SQL instance and its metadata.
• roles/monitoring.viewer – to read the instance's host and database metrics.
• roles/logging.viewer – to read the PostgreSQL error logs and query execution plans.

You can grant these roles with the gcloud CLI, replacing PROJECT_ID and the service account email:

for ROLE in roles/cloudsql.viewer roles/monitoring.viewer roles/logging.viewer; do
  gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:redgatemonitor@PROJECT_ID.iam.gserviceaccount.com" \
    --role="$ROLE"
done

In the "redgatemonitor" utility database, create the pg_stat_statements extension:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

To enable host monitoring, provide Redgate Monitor with a Google Cloud service account key (JSON). Grant the service account the following IAM roles on the project that contains the AlloyDB cluster:

• roles/alloydb.viewer – to discover the AlloyDB cluster and instance and their metadata.

• roles/monitoring.viewer – to read the instance's host and database metrics.

• roles/logging.viewer – to read the PostgreSQL error logs and query execution plans.

You can grant these roles with the gcloud CLI, replacing PROJECT_ID and the service account email:

for ROLE in roles/alloydb.viewer roles/monitoring.viewer roles/logging.viewer; do
  gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:redgatemonitor@PROJECT_ID.iam.gserviceaccount.com" \
    --role="$ROLE"
done

As a superuser, connect in turn to each database which you want Redgate Monitor to capture vacuum health data from. Then run the following for any Schemas or Tables in that database for which you want Redgate Monitor to collect vacuum health data:

Either (collect data for all tables within schema)

--Grant permissions for an entire schema within the database:
GRANT SELECT ON ALL TABLES IN SCHEMA myschema TO redgatemonitor;

Or (collect data for only specific tables)

--Or alternatively selectively grant permissions for an individual table:
GRANT SELECT on myschema.mytable to redgatemonitor;