TencentDB for PostgreSQL

User Guide

Product Documentation

Copyright in this document is exclusively owned by Tencent Cloud. You must not reproduce, modify, copy or distribute in any way, in whole or in part, the contents of this document without Tencent Cloud's the prior written consent.

Trademark Notice

All trademarks associated with Tencent Cloud and its services are owned by the Tencent corporate group, including its parent, subsidiaries and affiliated companies, as the case may be. Trademarks of third parties referred to in this document are owned by their respective proprietors.

Service Statement

This document is intended to provide users with general information about Tencent Cloud's products and services only and does not form part of Tencent Cloud's terms and conditions. Tencent Cloud's products or services are subject to change. Specific products and services and the standards applicable to them are exclusively provided for in Tencent Cloud's applicable terms and conditions.

User Guide
Instance Management
Instance Lifecycle
Setting Instance Maintenance Time
Modifying Instance Configuration
Setting instance availability zone for disaster recovery or region disaster recovery
Modifying AZs
Terminating Instances
Restoring Instances
Eliminating Instances
Restarting Instances
Modifying Data Replication Mode
Switch Source-Replica Instance
Task List
Upgrading Instance
Instructions for Upgrading Kernel Minor Version
Kernel Minor Version Upgrade Principle Explanation
Kernel Minor Version Upgrade
Upgrade the Major Version of the Database
CPU Elastic Scaling
Introduction
Setting Automatic Scale-Out
Setting Custom Scale-Out
Enabling Event Alarms
Querying Effective Scaling Tasks
Billing Instructions
Read-Only Instance
Overview
Managing RO Groups
Removal Policy and Load Balancing
Account Management
Database Privilege Overview
Users and Permission Operations
Console Operation Instructions
PUBLIC Permission Operation
Database Management
Database Management via Console
Parameter Management
Setting Instance Parameters
Parameter Value Limits
Parameter Template
Setting soft_limit_connections Parameters
TencentDB for PostgreSQL UNLOGGED Table Usage Notes
Log Management and Analysis
Slow Query Analysis
Error logs
Execution Log Management
Log Shipping
Backup and Restoration
Backup Principles and Solutions
Backing up Data
Downloading Backup
Cloning Instance
Automatic Backup Settings
Restoring PostgreSQL Data on CVMs
Deleting Backup
Viewing Backup Space
Setting Backup Download Rules
Use Serverless Cloud Function to Transfer Historical Backups of PostgreSQL
Rollback to the Original Instance
Backup Recovery for Deleted Instances
Data Migration
DTS-Based Logical Migration
Instructions
Operation Guide
Verification Failure Handling
Database Connection Check
Dependency Check
Version Check
Incremental Migration Check
Structure Compatibility Check
Structure Conflict Check
Account Conflict Check
Parameter Configuration Conflict Check
Plugin Compatibility Check
Multi-Task Conflict Check
Long Transaction Check
Creating a Data Consistency Check Task
Physical migration based on DTS
Configure Physical Migration Tasks
Physical Migration Check Items
DTS-Based Data Sync
Usage Instructions
Synchronization Guidance
Handling Front Validation Failure
Connecting to DB Check
Object Dependency Check
Version Check
Source or Target Instance Permission Check
Incremental Migration Pre-Check
Structural Compatibility Check
Structure Conflict Checking
Account Conflict Check
Parameter Configuration Conflict Check
Plug-In Compatibility Check
Primary Key Dependency Check
Critical Parameter Check for Instances
Multitask Conflict Detection
Long transaction check
Extension Management
Extension Overview
Instructions About Plugin Limitations on Creating
Supported Extensions
Overview
TencentDB for PostgreSQL 9.3
TencentDB for PostgreSQL 9.5
Creating a Plugin in TencentDB for PostgreSQL Instance
postgres_fdw Extension for Cross-database Access
pg_roaringbitmap Extension for Bitwise Operation
Network Management
Overview
Modifying Network
Enabling Public Network Address
Enabling Public Network Services Through CLB
Access Management
Overview
Access Policy Syntax
Authorizable Resource Types
Console Examples
Data Security
TDE Overview
Enabling TDE
SSL Encryption Settings
Tenant and Resource Isolation
Database Resource Isolation
Security Groups
Managing Security Groups
Associating Instances with Security Groups
Monitoring and Alarms
Monitoring Feature
Alarming Feature
Tag
Overview
Editing Tag

User Guide

Instance Management

Instance Lifecycle

Last updated：2024-01-24 11:16:51

TencentDB for PostgreSQL instances have many status. Instances in different status support different operations. This document describes the instance lifecycle.
TencentDB for PostgreSQL instances have the following status:
﻿
Creating is the initial status of instances, and instances can be used normally after creation.
Running and Executing task mean that the instance is running normally. Specifically, Executing task means that the instance is performing operations, such as modifying its configurations.
If a monthly subscribed instance expires or a pay-as-you-go instance has overdue payment or is terminated by users, it is Isolated and moved into the recycle bin.
You can manually Restore an instance from the recycle bin. After that, it becomes Running again.
A pay-as-you-go instance will be retained in the recycle bin for up to three days. Three days later, it expires and will be eliminated automatically. Once eliminated, it is deleted completely, and cannot be restored or viewed in the console.

Setting Instance Maintenance Time

Last updated：2024-01-24 11:16:51

Overview
Maintenance time is a very important concept for TencentDB for PostgreSQL. To ensure the stability of your TencentDB for PostgreSQL instance, the backend system performs maintenance operations on the instance during the maintenance time. We highly recommend you set an acceptable maintenance time for your business instance, usually during off-peak hours, so as to minimize the potential impact on your business.
In addition, we also recommend you perform operations involving data migration during the maintenance time, such as instance specification adjustment. Currently, the maintenance time is supported by primary and read-only instances.
Take the database instance specification upgrade as an example. As this operation involves data migration, after the upgrade is completed, a momentary disconnection from the database may occur. When the upgrade is initiated, the Switch Time can be set to During maintenance time, so that the instance specification will be switched during the next maintenance time after the instance upgrade is completed. Note that when you select During maintenance time for Switch Time, the switch will not occur immediately after the database specification upgrade is completed; instead, the sync will continue till the instance goes into the next maintenance time when the switch will be performed. As a result, the overall time it takes to upgrade the instance may be extended.
Note: 
Before maintenance is carried out for TencentDB for PostgreSQL, notifications will be sent to the contacts configured in your Tencent Cloud account through SMS and email.
Instance switch is accompanied by a disconnection from the database lasting for just seconds. Make sure that your business has a reconnection mechanism.
Directions
Setting maintenance time
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance details page.
2. In the Maintenance Info section on the instance details page, click Modify.
﻿
﻿
3. In the pop-up window, select Maintenance Window and Maintenance Time as needed and click OK.
﻿
﻿
Switching now
If a task is configured to be switched during the maintenance time, but you need to switch it urgently under special circumstances, you can click Switch Now in the Operation column.
Note: 
Switching now is applicable to operations involving data migration such as instance specification upgrade.

Modifying Instance Configuration

Last updated：2025-07-22 20:25:30

This document describes how to modify the computing specification and storage capacity of a TencentDB for PostgreSQL instance.
Overview
When the current performance or storage capacity of an instance fails to meet the demands of evolving business needs, you can perform configuration adjustments on the instance to accommodate the requirements of business growth.
Directions
1. Log in to the TencentDB for PostgreSQL console, select the target instance in the instance list, and select More > Adjust Configurations from the Operation column.
2. In the pop-up window, select the instance configuration and storage capacity you want to adjust to. The specific configuration adjustment price will be displayed below. After confirming the price, click Submit.
Note: 
As the instance configuration adjustment involves instance data migration, the adjustment process will be completed with a primary/secondary switch, which will cause an instantaneous disconnection and slightly affect business access to the database instance. Therefore, we recommend you set the switch time within off-peak hours.
If you need to control the switch time, please select Specify Time in Switch Time. Then, you can select a time range. After the instance data is migrated, the system will automatically check whether it is within the switch time range, and if not, the instance will enter the Waiting for Switch status until the time falls in the time range and then complete the switch.
The time range is calculated at the granularity of one day. If the time window on the current day is missed, switch will be performed in the time window on the next day.
When the instance is in the Waiting for Switch status, you can click Switch Now in the instance list to switch immediately.
﻿

Setting instance availability zone for disaster recovery or region disaster recovery

Last updated：2025-08-14 16:25:52

TencentDB for PostgreSQL allows cross-AZ disaster recovery and cross-region disaster recovery. The following explains them separately.
Setting Cross-AZ Disaster Recovery
This document describes how to modify the primary and standby AZs of an instance in the TencentDB for PostgreSQL console. Modifying AZs has no impact on the instance’s properties, configurations, or connection addresses. The amount of time required to modify AZs depends on the data volume of the instance.
Overview
Compared with a single-AZ deployment scheme, a multi-AZ one has better disaster recovery capabilities and can protect your databases from being affected by database instance failures, AZ outages, and even IDC-level failures.
Multi-AZ deployment provides database instances with high availability and failover support. Multiple AZ deployment is to combine several single AZs in the same region into a physical zone based on single-AZ deployment.
Notes
The region where the instance is located include at least two AZs.
The target AZ has sufficient computing resources.
Because a read-only instance has only one node, it cannot use the multi-AZ deployment scheme. When the AZs of its primary instance are changed, the region where the read-only instance resides remains unchanged.
Fees
No additional charge needs to be paid for the time being.
Directions
To create an instance, select an AZ on the Purchase page
1. Log in to the TencentDB for PostgreSQL console, and click Create.
2. On the Purchase page, select the corresponding region, and under this region, set the Primary AZ and Standby AZ fields.
﻿
3. After the purchase, you can enter the Instance Details page to query the primary and secondary AZs in the Availability Info area.
Modifying an Availability Zone in the Console
1. Log in to the TencentDB for PostgreSQL console, select the desired region, and click the name of the desired instance to enter the instance management page.
2. On the Instance Details page, click Modify AZ in the Availability Info area.
﻿
3. In the pop-up window for modifying deployment information, select the availability zone for either the primary or standby database.
Note:
Synchronous replication is used by default, which prioritizes data integrity. Therefore, the instance performance may be affected by the log transmission efficiency.
4. Select the switch time, and click OK.
Specify time: The switch will occur during the period of time you select.
Upon modification completion: The switch will occur right after the modification is completed.
Note:
Modifying the primary AZ of an instance will trigger an instance switch, during which the database will be temporarily disconnected. Please be sure that your services can be reconnected. However, modifying the standby AZ has no impact on instance access.
5. Once the instance status changes from Modifying AZ to Running, the AZ switch is complete.
Setting Cross-Region Disaster Recovery
Directions
1. Log in to the TencentDB for PostgreSQL console, and click Create. Purchase two TencentDB for PostgreSQL instances A and B. In this documentation, Instance A serves as the source instance, while Instance B acts as the target instance.
2. In the TencentDB for PostgreSQL console, click Data Migration to enter the data migration console.
﻿
3. In the Data Migration Console, click Create Data Migration Task and select the appropriate parameters. Set both the source and target instance types to PostgreSQL.
Note：
When creating a new data migration task, ensure that the region of the source instance aligns with the region of Instance A, and the region of the target instance corresponds to the region of Instance B.
﻿
4. After the task is created, start configuring the parameters. Set Access Type to Database, select instance A as the source and instance B as the destination, and enter the accounts and passwords for connectivity tests.
﻿
5. Set Migration Type to Full + incremental migration, and Migration Object to Entire instance.
﻿
The above steps can realize data synchronization from instance A to instance B in a different region, ultimately implementing cross-region disaster recovery for instance A.

Modifying AZs

Last updated：2024-01-24 11:16:51

This document describes how to modify the primary and standby AZs of an instance in the TencentDB for PostgreSQL console. Modifying AZs has no impact on the instance’s properties, configurations, or connection addresses. The amount of time required to modify AZs depends on the data volume of the instance.
Background
Compared with a single-AZ deployment scheme, a multi-AZ one has better disaster recovery capabilities and can protect your database from being affected by database instance failures, AZ outages, and even IDC-level failures.
The multi-AZ deployment scheme guarantees the high availability and failover capability of database instances by combining multiple AZs in the same region into a single "multi-AZ".
Notes
The region where your instance resides should have at least two AZs.
The target AZ has sufficient computing resources.
Because a read-only instance has only one node, it cannot use the multi-AZ deployment scheme. The region where the read-only instance resides will not change if the AZs of its primary instance change.
Costs
There is no additional charge for the time being.
Directions
Selecting AZs on the instance purchase page
1. Log in to the TencentDB for PostgreSQL console and click Create.
2. On the displayed purchase page, select a region, Primary AZ, and Standby AZ.
﻿
3. After the instance is purchased, you can view its primary and standby AZs in the Availability Info block on the Instance Details tab.
Modifying AZs in the console
1. Log in to the TencentDB for PostgreSQL console. In the instance list, select a region and click an instance ID to access the instance management page.
2. Click Modify AZ in the Availability Info block on the Instance Details tab.
﻿
3. In the pop-up Modify Deployment Info window, select AZs for the primary node and the standby node, respectively.
Note: 
The default data replication mode is synchronous replication, which prioritizes data integrity. The instance performance is affected by the log transmission efficiency.
4. Select the switch time and click OK.
Specify time: The switch will occur during the period of time you select.
Upon modification completion: The switch will occur right after the modification is completed.
Note: 
Modifying the primary AZ of an instance will trigger an instance switch, during which the database will be temporarily disconnected. Make sure that your business has a reconnection mechanism. However, modifying the standby AZ has no impact on instance access.
5. After the instance status changes from Modifying AZ to Running, the AZ modification is completed.

Terminating Instances

Last updated：2024-01-24 11:16:51

This document describes how to terminate a TencentDB for PostgreSQL instance in the console.
Overview
You can manually terminate instances at any time as needed. Terminated instances will be moved to the recycle bin.
Notes
If a pay-as-you-go instance is terminated, it will be moved to the recycle bin and retained there for up to three days. The instance in the recycle bin is in the "Isolated" status and cannot be accessed.
To use the instance again, you can restore it from the recycle bin.
If the instance in the recycle bin is no longer needed, you can eliminate it.
After the instance is eliminated, its data and backup files will also be deleted and cannot be restored in the cloud. Please store your backup files safely elsewhere in advance.
If a primary instance has one or more read-only instances, terminating the primary instance won't affect the read-only instances, but eliminating the primary instance will eliminate the read-only instances at the same time. To prevent instances from being eliminated due to overdue payment, please pay attention to the instance expiration information.
If a pay-as-you-go instance is terminated, its billing stops.
Directions
1. Log in to the TencentDB for PostgreSQL console, locate the instance to be terminated in the instance list, and click More > Terminate Instance in the Operation column.
2. In the pop-up dialog box, indicate your consent and click Terminate Now.
﻿

Restoring Instances

Last updated：2024-01-24 11:16:51

This document describes how to restore an isolated TencentDB for PostgreSQL instance in the console.
Overview
If an instance is terminated by mistake, due to overdue payment, or when it expires, you can go to the recycle bin to restore it before it is eliminated.
Note: 
After an instance is restored, it uses the same configurations as before.
An instance cannot be terminated, restored and terminated again in a short time.
Directions
1. Log in to the TencentDB for PostgreSQL console, locate the instance to be restored in the recycle bin list, and click Restore in the Operation column.
2. In the pop-up dialog box, confirm the billing information, and click Confirm.
﻿
﻿
3. After the restoration is completed, you can see the instance in the instance list.

Eliminating Instances

Last updated：2024-01-24 11:16:51

This document describes how to eliminate an isolated TencentDB for PostgreSQL instance in the console.
Overview
You can manually eliminate an instance when you confirm that the instance is no longer needed.
Note: 
After the instance is eliminated, its data and backup files will also be deleted and cannot be restored in the cloud. Please store your backup files safely elsewhere in advance.
If a primary instance has one or more read-only instances which are running normally, the read-only instances will be eliminated along with the primary instance. To prevent instances from being eliminated due to overdue payment, please pay attention to the instance expiration information.
Directions
1. Log in to the TencentDB for PostgreSQL console, locate the desired instance in the recycle bin list, and click Eliminate in the Operation column.
2. In the pop-up dialog box, confirm that everything is correct and click Confirm.
﻿
﻿

Restarting Instances

Last updated：2025-08-05 11:22:59

Restart is indispensable to the maintenance of databases. Restarting a PostgreSQL instance is equivalent to restarting a database (service and process) on a local server.
Notes
Please exercise great caution when restarting a database, which plays a vital role in the business. Before the restart, it is recommended to disconnect the database from server and stop writing data.
Restarting an instance does not change its physical attributes, so the public IP, private IP, and any data stored on the instance will remain unchanged.
After the restart, reconnection to the database is needed. Please make sure your business has a reconnection mechanism.
Be sure to restart the instance during off-hours so as to ensure success and reduce impact on your business.
Directions
1. Log in to the TencentDB for PostgreSQL console, locate the desired instance in the instance list, and click More > Restart in the Operation column.
Note: 
Generally, it takes a few seconds to minutes to restart an instance, during which the instance cannot be accessed and existing connections to it will be closed.
Restart will fail if there are a large number of writes and dirty pages during the restart. In this case, the instance will roll back to the status before the restart and can still be accessed.
There is a chance of failure in restarting a database. If it takes more than 10 minutes to restart, you can submit a ticket for help.
﻿
2. In the pop-up dialog box, indicate your consent and click OK.
﻿

Modifying Data Replication Mode

Last updated：2025-05-21 15:53:27

Supported Methods to Replicate Data
Database instance replication refers to the process of synchronizing data by configuring one or more backup databases for the server, distributing PostgreSQL data across multiple systems. TencentDB for PostgreSQL supports two kinds of data replication methods: asynchronous replication and semi-synchronous replication.
Asynchronous Replication
Asynchronous replication for TencentDB for PostgreSQL adopts the one-master-one-standby architecture.
After receiving a data update (including insert, update and delete operations) request from an application, the master performs the update operation. When the update is completed, the master immediately responds to the application and replicates the data to the slave.
In the process of data update, the master does not need to wait for the response of the slave. Therefore, the database instances of asynchronous replication usually have higher performance (for specific performance, see Test Results), and the unavailability of the slave does not affect the service provided by the master. However, because the data is not synchronized to the slave in real time, if a fault occurs on the master while the slave is delayed and a switch occurs, there is a slight chance of causing data inconsistency.
Note:
By default, TencentDB for PostgreSQL adopts asynchronous replication for data replication.
Semi-synchronous Replication
Semi-synchronous replication of TencentDB for PostgreSQL adopts a one-master-one-standby architecture.
An application initiates a data update request (including insert, update, delete operations). After the master completes the update operation, it immediately replicates the data to the slave. Only after the slave receives the data and writes it to the WAL (without executing), it returns a success message to the master. The master must only return a response to the application program after receiving the success message from the slave.
Only when an exception occurs in data replication (the Slave node is unavailable or an exception occurs in the network used for data replication), the Master will pause (about 10 seconds by default in PostgreSQL) responding to the application. The system will downgrade the replication mode to asynchronous replication. When data replication returns to normal, the system will restore the replication mode to semi-synchronous replication.
Degradation Description
The operation in which the system automatically changes the data replication mode from semi-synchronous replication to asynchronous replication according to specified conditions is called degradation. Degradation includes two situations: fault degradation and delayed degradation.
Fault Degradation
If the current primary-backup data replication mode of TencentDB for PostgreSQL is semi-synchronous, when an exception occurs in data replication (the Slave node is unavailable or an exception occurs in the network used for data replication), the Master will pause responding to the application (about 10 seconds by default in TencentDB for PostgreSQL) and downgrade the primary-backup replication mode to asynchronous to ensure system availability. When the high-availability system detects that data replication has returned to normal, it will restore the primary-backup data replication mode to semi-synchronous.
Note:
Failure degradation is the default behavior of the high-availability system of TencentDB for PostgreSQL. To ensure system high availability, customizing is not supported at present.
Latency Degradation
If you have specific needs, you can enable latency degradation under semi-synchronous replication. Once delayed degradation is enabled, TencentDB for PostgreSQL's high-availability system will determine the master-slave replication latency based on the conditions you have set. Exceeding the latency will trigger semi-synchronous degradation to asynchronous. It is recommended that only this feature be enabled for highly latency-sensitive businesses.
The conditions for latency degradation are the size or time of master-slave synchronization. You can refer to the metrics of log write delay (bytes) and log write time delay (seconds) on the standby database. For more details, see Master/Slave Latency Monitoring Metrics.
Failover Description
When the primary/replica replication mode of an instance is asynchronous replication or semi-synchronous replication downgrades to asynchronous replication, a primary/standby switch will be triggered if the Master fails and cannot be recovered. Since data is not synchronized to the Slave in real time, there is a slight chance of data inconsistency after the switch. TencentDB for PostgreSQL enables you to flexibly set the failover conditions. By default, switching is allowed when both primary/replica delay <= 10240 MB and primary/secondary delay <= 10 seconds are met. It is advisable that you make settings only when you have special business needs.
Modifying Data Replication Mode
1. Log in to the PostgreSQL Console. In the instance list, click the Instance ID or Operation in the Manage column to open the instance details page.
2. In the Availability Info section of the instance details, detailed availability information of the instance is displayed.
2.1 When the data replication mode is asynchronous, the specific display information is as follows:
Information
Description
Data Replication Mode
For the data synchronization mode between the master and the slave, the current two-machine high availability (one master and one slave) architecture supports Async ( Asynchronous replication )and Semi-Sync ( Semi-synchronous replication ).
Instance Status
Display the current accessibility status of the instance. When the status is normal, normally receive user requests. If an abnormal display occurs, it indicates that the instance currently cannot receive application requests.
﻿
﻿
Failover Condition
When the Master node fails and cannot be recovered, automatic failover is required, with the Slave providing services. At this point, the system defines the failover conditions, which are the size and time of primary-backup latency. The default system conditions are less than or equal to 10240 MB and 10 seconds. For specific switch conditions, refer to Failover Description.
Primary AZ
It refers to the availability zone of the master node.
Standby AZ
It refers to the availability zone of the slave node.
2.2 The specific display information is as follows when the data replication mode is semi-synchronous:
Information
Description
Data Replication Mode
For the data synchronization mode between the master and the slave, the current two-machine high availability (one master and one slave) architecture supports Async ( Asynchronous replication )and Semi-Sync ( Semi-synchronous replication ).
Instance Status
It displays the current accessibility status of the instance. When the status is normal, user requests are normally received. If the status is abnormal, the instance currently cannot accept application requests.
Delay Downgrade Condition
When the data replication mode of the instance is semi-synchronous replication, the system will automatically degrade the master and slave replication method to asynchronous to ensure system availability outside the range of user-set conditions. This degradation condition is the master and standby latency size or latency time. Among them, PostgreSQL instances with a large version number of 9 only support the condition of master and standby latency size. For details, see Degradation Description.
Failover Condition
When the master node fails and cannot be recovered, an automatic failover is required, to switch to the slave to provide service. At this time, the system has defined the failover conditions, which are the size or time of master-slave latency. Applications can modify the switch conditions based on special needs. For details, see Failover Description.
Primary AZ
It refers to the availability zone of the master node.
Standby AZ
It refers to the availability zone of the slave node.
3. Click Modify to change the current instance's data replication mode.
Note:
Changes to the data replication mode are effective immediately, and modifying the data method may cause a master/slave switch. There will be a momentary disconnection during the master/slave switch, please ensure the application is reconnected.
﻿

Switch Source-Replica Instance

Last updated：2025-05-21 15:53:27

Reason for Master/Slave Switch
Interchange of master and slave node roles within an instance is called a master/slave switch. After the switch, the instance address remains the same, and the application automatically connects to the new master node, thereby ensuring high availability of the instance. The main reasons for the master/slave switch are:
Failover
The system automatically initiates a master/slave switch when it detects that the instance is abnormal and cannot be used normally. For specific switch conditions, see Failover Description.
Manual Switch
It refers to the master/slave switch initiated manually by application Ops personnel or authorized Tencent Cloud technical experts. Manual switch includes the switches with normal master-slave latency and forced switches with latency exceeding the master-slave latency.
Forced Switch
When the instance's master-slave replication mode is asynchronous replication or when semi-synchronous replication is degraded to asynchronous replication, a master/slave switch will be triggered if the master fails and cannot recover. As the data is not synchronized to the slave in real time, there is a small chance that data inconsistency might occur. Conditions for allowing switches are configured in the system by default, but you can also set specific conditions based on the needs of your business. Therefore, a switch is only allowed when the switch conditions are met. To facilitate switches in emergencies, the system provides forced switch capability.
Note:
To prevent changes in switch conditions over time, when a force switch is performed, the switch must be performed immediately.
Impact of Master/Slave Switch
There will be a momentary disconnection during the master/slave switch process. Please ensure that your application has a reconnection mechanism.
If there are read-only instances mounted on the master instance, there will be a minute-level delay after the master/slave switch.
Manual Switch of Instances
1. Log in to the PostgreSQL Console. In the instance list, click the Instance ID or Manage in the Operation column to enter the instance detail page.
2. In the Availability Info section of the instance details, click on Primary-Standby Switch.
﻿
﻿
View Change Record
1. Log in to the PostgreSQL Console. In the instance list, click the Instance ID or Manage in the Operation column to enter the instance detail page.
2. In the Availability Info section of the instance details, click Switch Records. The system will retain switch records for one year.
﻿
Master/Slave Latency Monitoring Metrics
TencentDB for PostgreSQL provides detailed monitoring information to help you observe the synchronization latency between the master and slave nodes. The specific monitoring metrics are as follows:
Metric Name
Metric Description
Slave Log Write-to-Disk Latency (Bytes)
It refers to the difference in size between the slave log write-to-disk LSN and the current LSN of the master instance. For the master instance, this metric reflects the data loss size in the event of a failover.
Slave Log Write-to-Disk Time Latency (Seconds)
The time difference between the transmission of logs from the primary database to the secondary database and the reception and persistence of these logs on the secondary database reflects the potential data loss during failover for the primary instance. This metric is available only for instance versions 10.x and above.
Master-Slave Data Synchronization Latency (Bytes)
It refers to the difference in size between the slave replay LSN and the current LSN of the master instance. For the master instance, this metric reflects the RTO in the event of a failover. For read-only instances, this metric reflects the data latency size.
Master-Slave Data Synchronization Latency Time (Seconds)
The time difference between the transmission of logs from the primary database to the secondary database and the reception and replay of these logs by the secondary database. This metric is available only for instance versions 10.x and above.
Slave Log Send and Replay Position Difference (Bytes)
It refers to the size difference between the master instance sending the log to the slave instance and the completion of slave log replication. It reflects the speed of slave log application. You can mainly check the performance of the slave instance and the speed of network transmission through this metric. This metric is not available for read-only instances.

Task List

Last updated：2025-06-09 10:26:09

You can view the details of executed tasks through the TencentDB for PostgreSQL Console, enabling you to conveniently monitor the progress of operations performed on instances. This article provides guidance on how to access the task list via the console and manage tasks effectively.
Task Type
Through the task list, you can view the following types of tasks: Instance initialization, instance configuration adjustment, instance restart, minor version upgrade, major version upgrade, pre-check of major version upgrade, enabling public network (environment not available), disabling public network (environment not available), creating a read-only group, changing the read-only group for a read-only instance, adding a read-only instance to a read-only group, removing a read-only instance from a read-only group, cloning an instance, database and table rollback, adding a network, deleting a network, enabling auditing (environment not available), disabling auditing (environment not available), changing the availability zone of an instance, parameter configuration, terminating an instance, taking an instance offline, physical migration, and primary/secondary switch.
Note：
The task list allows querying tasks within the past 180 days.
Viewing the Task List
1. Log in to the PostgreSQL console.
2. In the left sidebar, click Task List to enter the task list page.
3. Select the corresponding region at the top.
4. You can directly search tasks or retrieve them by keywords in the task list to view the task details.
﻿
Searching Keywords
In the task list, you can use the search box to quickly find the target task by entering keywords. The search box supports searching by resource attributes such as task ID or instance ID.
﻿
Downloading Task Data
1. Log in to the PostgreSQL console.
2. In the left sidebar, click Task List to enter the task list page.
3. Select the corresponding region at the top.
4. Click the download button 
﻿
 after the search box to download the data on the current page or under the current query conditions.
Viewing Task Details
1. Log in to the PostgreSQL console.
2. In the left sidebar, click Task List to enter the task list page.
3. Select the corresponding region at the top.
4. Find the task for which you need to query the task details, and click Task Details in the Operation column.
﻿
﻿
As shown in the figure above, for certain tasks, the system provides the configuration information before and after the task execution in the task details for your reference. The input is the configuration information before the task execution, while the output is the configuration information after the task execution. The table below will explain the input and output of each task in detail.
Task Type
Input
Output
Adjusting instance configuration
{
"Cpu":"2 core"//CPU configuration before instance adjustment.
"Memory":"4 GiB"//Memory configuration before instance adjustment.
"Storage":"10 GB"//Storage space configuration before instance adjustment.
}
{
"Cpu":"2 core"//CPU configuration after instance adjustment.
"Memory":"4 GiB"//Memory configuration after instance adjustment.
"Storage":"20 GB"//Storage space configuration after instance adjustment.
"Message":"success"//Specific returned result of the task. Success indicates success. For other statuses, see the specific information.
}
Changing the read-only group for a read-only instance
{
"NewROGroupId":"pgrogrp-3p21ssox"//Target read-only group ID.
"OldROGroupId":"pgrogrp-dct9wsml"//Source read-only group ID.
"ROInstanceId":"pgro-a9qea3c9"//Read-only instance ID.
}
{
"NewROGroup":{//Target read-only group details.
"ROGroupId":"pgrogrp-3p21ssox"
"ROGroupIp":"10.0.0.2"
"ROGroupName":"1"
"ROGroupPort":5432
}
"OldROGroup":{//Source read-only group details.
"ROGroupId":"pgrogrp-dct9wsml"
"ROGroupIp":"10.0.0.6"
"ROGroupName":"2"
"ROGroupPort":5432
}
"ROInstance":{//Read-only instance details.
"ROInstanceId":"pgro-a9qea3c9"
"ROInstanceIp":[
0:"10.0.0.17"
]
"ROInstanceName":"Unnamed"
"ROInstancePort":5432
}
}
Adding a read-only instance to a read-only group
{
"ReadOnlyGroupId":"pgrogrp-3p21ssox"//Target read-only group ID.
"ReadOnlyInstanceId":"pgro-82nkylkb"//Read-only instance ID.
}
{
"ROGroup":{//Target read-only group details.
"ROGroupId":"pgrogrp-3p21ssox"
"ROGroupIp":"10.0.0.2"
"ROGroupName":"1"
"ROGroupPort":5432
}
"ROInstance":{//Read-only instance details.
"ROInstanceId":"pgro-82nkylkb"
"ROInstanceIp":[
0:"10.0.0.10"
]
"ROInstanceName":"Unnamed"
"ROInstancePort":5432
}
}
Removing a read-only instance from a read-only group
{
"ROGroupId":"pgrogrp-3p21ssox"//Source read-only group details.
"ROInstanceId":"pgro-a9qea3c9"//Read-only instance ID.
}
{
"ROGroup":{//Source read-only group details.
"ROGroupId":"pgrogrp-3p21ssox"
"ROGroupIp":"10.0.0.2"
"ROGroupName":"1"
"ROGroupPort":5432
}
"ROInstance":{//Read-only instance details.
"ROInstanceId":"pgro-a9qea3c9"
"ROInstanceIp":[
0:"10.0.0.17"
]
"ROInstanceName":"Unnamed"
"ROInstancePort":5432
}
}
Adding a network
{
"DBInstanceId":"postgres-6s1kuw28"//Instance ID.
"IsAssignVip":false//Whether the assigned VIP is registered. All are false here.
"SubnetId":"subnet-piadji8r"//Subnet ID.
"Vip":""//The VIP that is about to be assigned. All are empty here.
"VpcId":"vpc-fz41fhgo"//Virtual Private Cloud (VPC) ID.
}
{
"DBInstanceId":"postgres-6s1kuw28"//Instance ID.
"DBInstanceNetInfo":{//Details of the newly added network.
"Address":""
"Ip":"10.0.10.15"
"Port":5432
"Status":"opened"
"NetType":"private"
"VpcId":"vpc-fz41fhgo"
"SubnetId":"subnet-piadji8r"
"ProtocolType":"postgresql"
}
}
Deleting a network
{
"DBInstanceId":"postgres-6s1kuw28"//Instance ID.
"SubnetId":"subnet-piadji8r"//Subnet ID.
"Vip":"10.0.10.15"//VIP to be deleted.
"VpcId":"vpc-fz41fhgo"//Virtual Private Cloud (VPC) ID.
}
{
"DBInstanceId":"postgres-6s1kuw28"//Instance ID.
"DBInstanceNetInfo":{//Details of the deleted network.
"Address":""
"Ip":"10.0.10.15"
"Port":5432
"Status":"closed"
"NetType":"private"
"VpcId":"vpc-fz41fhgo"
"SubnetId":"subnet-piadji8r"
"ProtocolType":"postgresql"
}
}
Parameter configuration
{
"Name":"max_connections"//Modify the parameter name.
"ExpectedValue":"2040"//Modify the parameter target value.
}
{
"max_connections":{//Parameter name.
"message":"this parameter must be modified on the master node first and reboot"//Prompt information for reference.
"modify_after_value":"2040"//Target value of the parameter.
"modify_before_value":"2048"//Original value of the parameter.
"status":"success"//Modification status.
}
}

Upgrading Instance

Instructions for Upgrading Kernel Minor Version

Last updated：2024-11-04 09:36:12

Overview
In most scenarios, kernel minor version upgrade is not mandatory. The system will provide you with the latest minor version for upgrade. For an introduction to the minor version, refer to Kernel Version Updates. You can complete the Upgrade Minor Kernel Version by yourself in the console based on your business needs.
Extreme Conditions
In extreme conditions such as major defects, security issues, or known potential risks, the system will notify you in advance via SMS, email, and the Message Center (the actual notification method is based on your Message Center subscription configuration). During the maintenance time of TencentDB for PostgreSQL instances, the system will automatically initiate and complete the mandatory upgrade of the database kernel minor version.
Impact of Kernel Minor Version Upgrades
If the instances of the kernel version to be upgraded are associated with other instances (read-only instances), the upgrade will be performed for these instances together to ensure data replication consistency.
TencentDB for PostgreSQL version upgrade may involve data migration. The migration speed typically depends on data volume. Your business will not be affected during upgrade and will be accessible as usual.
Upon completion of minor version upgrades, instance switching will occur, which may cause momentary disconnection. You are recommended to enable the automatic reconnection feature of applications.
You are recommended to Set Instance Maintenance Time via the console or API to avoid mandatory upgrades during business peak periods.

Kernel Minor Version Upgrade Principle Explanation

Last updated：2025-07-22 20:25:30

Upgrade Necessity
TencentDB for PostgreSQL periodically releases new kernel minor versions, bringing feature improvements and optimizations, fixing related issues, effectively avoiding potential risks, and guaranteeing database stability and security. You are recommended to reasonably plan kernel minor version upgrade time according to your own business needs and upgrade strategy to ensure the database version is the latest. This document explains the principles behind kernel minor version upgrade in detail.
Upgrade Processing Process
﻿
Compatibility Check
After the user initiates an upgrade task, the system first performs the following pre-check:
1. Kernel compatibility check: The system backend automatically detects the compatibility between the kernel minor version of the current database instance and the target minor version to prevent abnormal risks.
2. Parameter compatibility check: The system will detect whether user-defined parameters and system-managed parameters are compatible with the new version to prevent invalid parameters or conflicts. For user-defined parameters, if the parameter range corresponding to the target kernel version differs from that of the original kernel version, the system will provide a prompt when the parameter value exceeds the requirement of the target kernel version, allowing users to perform self-modification, as shown below.
﻿
3. Plug-in compatibility check: The system will detect whether installed plug-ins are supported by the new kernel minor version to avoid upgrade failure or feature exceptions caused by incompatible plug-ins.
Confirm Upgrade Sequence
Upgrading a Read-Only Instance
After the compatibility check is complete, the system will determine the instance type that requests the upgrade.
If the instance is read-only, directly enter the upgrade process;
If the instance is primary, start by upgrading all associated read-only instances. Once all read-only instances are upgraded, proceed with the primary instance upgrade process.
Note:
When initiating a kernel minor version upgrade task for the primary instance, all associated isolated, decommissioned but unrecovered read-only instances will also be upgraded. Both the primary and standby instances will enter the "upgrading kernel version" status. Instances in this status can still log in to use normally but are unable to perform management operations. Once an instance upgrade is complete, its status will restore to "running".
﻿
Note: If the primary node has multiple associated read-only instances, the read-only instances will be upgraded sequentially. Confirm the upgrade window in advance and ensure the business has a reconnection mechanism.
For the primary instance, to ensure high availability, the system will first upgrade the replica node. After the standby node upgrade is complete, proceed with the primary node upgrade.
Upgrading the Primary Instance
For the primary instance currently in the upgrade process, the system will pull a new secondary node with the same specification type as the original instance, sync data from the primary node to the new secondary node, and complete the upgrade on this secondary node. After the upgrade is completed, a primary/replica switch will be performed within the switch time specified by the user.
﻿
Updating Parameters at the Instance Level
During the upgrade, some parameters may be adjusted. Certain changes require restarting the database for the changes to take effect. Ensure your business has a reconnection mechanism.
Upgrade Task Completion
After the upgrade task ends, the upgrade task record will be displayed in version upgrading on the instance details page.
For a read-only instance, the upgrade task ends once the instance upgrade is complete.
For a primary instance, the upgrade task ends once all primary and secondary nodes are upgraded.
﻿
FAQs
Kernel Minor Version Upgrade after Downgrade Is It Possible
TencentDB for PostgreSQL does not support kernel minor version downgrade.
Impact of Upgrading Kernel Minor Version
Upgrading the minor kernel version will restart the instance and trigger a switchover. Generally, the service may experience a 30-second interruption once, with the specific time depending on the business scenario. We recommend choosing the instance maintenance time for the switchover and ensuring user applications have the automatic reconnection feature.
Active/standby switch can cause logical replication slot loss, leading to logical replication disconnection. To prevent inconvenience, please use logical replication slot fault migration (Failover Slot) capacity.

Kernel Minor Version Upgrade

Last updated：2025-05-21 15:53:27

TencentDB for PostgreSQL allows you to upgrade kernel minor version, so you can use new features, improve performance, or fix issues.
For detailed information on the supported kernel versions of TencentDB for PostgreSQL, please refer to Kernel Version Update History.
Overview
You can manually upgrade kernel minor version in the console.
Upgrade Rules
If an instance to be upgraded is associated with other instances (e.g., read-only instances), these instances will be upgraded together to ensure data consistency.
Version upgrade of TencentDB for PostgreSQL may involve data migration. Usually, the migration speed is related to the amount of data. Please wait patiently. During the upgrade period, your business will not be affected and can be accessed normally.
Note
Upon completion of the minor version upgrade, an active/standby switch will be involved, and the database will experience a momentary disconnection lasting a few seconds. It is recommended to perform the switch during the instance maintenance time, and the application has the automatic reconnection feature.
The kernel minor version cannot be downgraded once upgraded.
Directions
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an Instance ID or Manage in the Operation column to enter the instance details page.
2. In the Configuration Info section, click Upgrade Kernel Minor Version.
﻿
3. In the pop-up window, set the target version to upgrade and click OK.
﻿
Note:
As database kernel minor version upgrade may involve data migration, a momentary disconnection from the database may occur after the upgrade is completed. We recommend that you set the switch time to During maintenance time, so that the switch will be initiated within the next maintenance time after the upgrade is completed.
When upgrading the minor kernel version of an instance, the backend checks the Instance Parameter List. If there are data discrepancies between the parameter ranges of the target kernel version and the original kernel version, and the parameter value exceeds the range specified by the target kernel version, a notification will be provided as shown below:
﻿

Upgrade the Major Version of the Database

Last updated：2025-07-22 20:25:30

Overview and Advantages
TencentDB for PostgreSQL continuously offers new versions for customer use. New versions introduce more features, better performance, higher stability, and enhanced security. It is recommended that you reasonably plan based on business needs and upgrade the database major version as soon as possible.
TencentDB for PostgreSQL supports major version upgrades, and this tool has the following advantages:
Supports cross-version upgrades among PostgreSQL 9 to 17. Supports upgrade rehearsals.
The upgrade is performed on a read-only instance pulled from the original instance, with no impact to the original instance.
During a major version upgrade, the instance will become a read-only instance within a certain period. The duration of the instance read-only depends on the number of original instance objects and is irrelevant to the data scale.
During the statistics collection period, the instance will also become read-only. The duration of the read-only state depends on the amount of data.
After the original instance upgrade is completed, connection addresses, tags, monitoring, backup sets, and other information are fully retained.
Note:
It is strongly recommended that you initiate a drill before a major version upgrade so that you can more clearly estimate the instance read-only time.
Not currently supported to perform a major version upgrade on instances with transparent data encryption (TDE) enabled.
The major version cannot be downgraded. Currently, TencentDB for PostgreSQL major versions are fully compatible with old versions. It is recommended that you preferentially use higher versions.
Directions
Formal Major Version Upgrade
1. Log in to the PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to enter the instance details page.
2. Click Version Upgrade to open the version upgrade operation page.
﻿
3. Click Upgrade Major Version to open the version upgrade page.
﻿
3.1 Target version
The system will provide all major versions available for upgrade at present, and users can choose. Only upgrading to the latest minor version under each major version is supported.
3.2 Upgrade time
During the upgrade process, there may be momentary disconnections and brief read-only periods. Therefore, business needs self-assessment of the operation time window. Immediate execution, specified time, or maintenance time are available options. For maintenance time settings, refer to Setting Instance Maintenance Time.
If the required preparations have been completed but the designated upgrade time has not yet arrived, the instance status will display as Waiting for Switch. You can directly start the upgrade by going to Instance List > Operation > Switch Immediately on the console.
3.3 Explanation of Statistical Information Collection
This operation mainly involves running ANALYZE on the primary instance and updating system statistics during the first launch of the database after the upgrade. Accurate statistical information ensures that the PostgreSQL query planner processes queries in the best way. Lack of statistical information may lead to errors in the query plan, which may decrease performance and occupy too much memory. The duration of generating statistical information depends on the size of the instance data volume. The instance will be read-only while generating statistical information.
3.4 Plugin upgrade setting
This operation mainly executes "ALTER EXTENSION UPDATE" on the database where plug-ins have been created after the upgrade is completed. Three upgrade times are supported:
Upgrade Time
Description
Upgrade plugins before completing the major version upgrade.
Under this method, you need to check the plugin list of all databases and upgrade the plugins to the corresponding versions. The execution time is positively correlated with the number of databases and the number of plugins, which will extend the execution time of the entire major version upgrade. Please assess and then select.
Upgrade plugins after completing the major version upgrade.
Under this method, the database will promptly resume read and write operations upon the completion of the major version upgrade, during which the plugins will undergo updates. However, during the plugin update period, the plugin features may become unavailable. When selecting this upgrade time, you need to evaluate whether your business will be affected.
Do not upgrade the plugin version
Under this method, the database will promptly resume read and write operations upon completion of the major version upgrade, without automatically upgrading plugins. If needed, you can manually upgrade the plugins. When selecting this upgrade time, you need to evaluate whether your business will be affected.
3.5 Whether to perform backup before the upgrade starts
When performing a major version upgrade, to ensure data recoverability, the system will automatically conduct two full backups by default. The backup type is upgrade backup:
Perform a full backup once before the upgrade starts, and perform it immediately at the commencement of the upgrade. If problems occur with the instance after a major version upgrade, users can use this backup to restore the database instance to the status of the previous version.
A full backup will be performed after the upgrade is completed. This backup is created immediately after new writes are allowed on the upgraded database instance.
Pre-upgrade backup supports two options:
Option
Description
Yes
Default option. Backup will incur fees. For details, reference Backup Space Billing. Users can choose to delete it after upgrade verification is completed. The deletion policy for this backup file is also managed by the user-configured backup retention rules.
If you want to extend the backup set retention time, enter the backup recovery interface and click 
﻿
 in the backup expiration time column to proceed with editing.
No
Select this option when the instance has backups that can be restored to the pre-upgrade state. Otherwise, it is not recommended.
3.6 Task launch settings
Option
Description
Check without initiating task
Only perform pre-upgrade checks, including instance running status, legitimacy of instance parameter settings, database connection check, etc., but do not initiate the task. Users can use this operation to pre-check the feasibility of the upgrade.
Check and initiate task
Perform pre-upgrade checks, including instance running status, legitimacy of instance parameter settings, and database connection check. If the check passes, directly initiate the task.
4. Click Submit to create an upgrade task. The instance status will change to Kernel Version Upgrading. Users can check the task status and system log in Upgrade Task List.
﻿
﻿
Drill Upgrade
To ensure the success rate of the upgrade, users can choose to conduct an upgrade drill first. The upgrade drill is based on the backup set of the current instance to clone a new instance first, then perform the upgrade on the new instance. After the upgrade is completed, a new instance will be generated. Users can choose to directly use the instance or delete it. Cloning to generate an instance will be billed normally in pay-as-you-go mode. For more details about the price, see Product Price. Specific operations are as follows:
1. Log in to the PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to enter the instance details page.
2. Click Version Upgrade to open the version upgrade operation page.
3. Click Major Version Upgrade Drill to enter the rehearsal operation interface.
3.1 Cloned instance settings
For specific cloned instance settings, see Cloning Instance.
﻿
3.2 Upgrade settings
Refer to Formal Major Version Upgrade for upgrade configuration items.
Click Submit to initiate a drill task. If the original instance is postgres-*******, the system will create a new instance named postgres-*******-pre-upgrade-************** and complete the subsequent upgrade.
How It Works
To help you understand the system, and manage the major version upgrade time, this article shows the operations performed by the system during major version upgrade, as shown in the figure below:
﻿
The above figure uses the upgrade from PostgreSQL 10 to PostgreSQL 14 as an example, and detailed description of the backend system operating steps are as follows:
1. Precheck
Check if the instance state is running.
Check the validity of instance parameters.
Check if the target upgrade version is valid.
2. Create a read-only instance
Create a read-only instance of the source instance, to minimize the impact of upgrades on the original instance. Subsequent upgrade operations will be performed on this read-only instance.
3. Initialize the new version database
Create a blank directory, and initialize a new instance with the target version. This new instance only has a single node.
4. Stop the high version node, and set source instance master node to read-only.
Stop the new version instance, and set the source instance to read-only.
5. Promote the read-only instance to the master instance, and stop the process.
Promote the read-only instance to the master instance, and stop this instance.
6. Perform the upgrade
Perform the upgrade, export and import the metadata, and process data.
7. Launch the new version process, switch routes, build new standby machines, and reclaim the old nodes.
Launch the upgraded new version instance, switch the routing information of the original instance, and set up a secondary node for the new instance. In the end, clean up the environment to finish the task.
Note:
After the system upgrade is completed, carry out relevant verification to ensure the smooth operation of the business as follows:
Please run a business load test on the database after the upgrade.
Verify extension compatibility.
Verify parameter compatibility.
System Limits
If the instance has associated read-only instances, you need to delete the read-only instances before initiating the upgrade.
If the disk space usage of an instance exceeds its limit, initiating a major version upgrade will not be possible.
FAQs
Is the Major Version Downgrade supported?
The major version downgrade is not supported. The current TencentDB for PostgreSQL is forward compatible with major versions, a higher version is recommended.

CPU Elastic Scaling

Introduction

Last updated：2025-11-20 09:44:41

Overview
TencentDB for PostgreSQL supports setting automatic and custom CPU scaling for instances, which effectively alleviates performance pressure caused by sudden requests, adapts to peak business traffic, and ensures the stability of online businesses. It also supports CPU scale-in during periods of decreased traffic to avoid resource waste. This document introduces the feature of CPU elastic scaling.
Feature Type
The CPU elastic scaling feature includes automatic scaling and custom scaling. When automatic scaling is enabled, you need to set scale-out and scale-in rules. When custom scaling is enabled, first select the number of cores for scale-out and then choose the scale-in time. For scale-out time, you can select now, which means the CPU will scale out immediately without automatic scale-in afterward, and this feature needs to be disabled manually. Alternatively, you can scale out the CPU by time period or cycle, where the CPU scales out within the selected period or cycle and automatically scales in within other periods. This enables more granular configuration of the CPU elastic scaling policy for instances, better aligning with actual business fluctuations.
Automatic Scaling
Automatic scale-out description
After Elastic CPU scale-out > Automatic scale-out is enabled, when the average CPU utilization of the database instance within the observation window reaches the set threshold, the system will double the number of CPU cores based on the original computing specification. For example, if the original computing specification has 4 CPU cores, it will be increased to 8 cores. If the user's Tencent Cloud account balance is insufficient or the host lacks sufficient CPU resources (which is less possible), scaling will not be performed, and a scaling failure event will be sent.
Note:
Only support doubling the number of CPU cores from the original computing specification. The already increased number of CPU cores cannot be further increased. For example, if the increased number of CPU cores is 8, it cannot be increased to 16 cores.
Automatic scale-in description
After Automatic scale-out under Elastic CPU scale-out is enabled, during the observation window set for the scale-in rules, if the CPU utilization falls below the set threshold, the system will automatically scale in the number of CPU cores back to the original computing specification.
Note:
After the Elastic CPU scale-out > Automatic scale-out feature is enabled, the system monitors the database instance based on the latest configuration parameters. When the database instance meets the automatic scale-in conditions, the system will automatically scale in the database instance.
For how to enable or disable automatic scale-out and set scaling rules, see Configuring Auto Scale-out.
Custom Scale-Out
Custom scaling description
When Elastic CPU scale-out > Custom scale-out is enabled, if the scale-out time is set to now, the instance will run with the increased number of CPU cores immediately. If the scale-out time is set by time period or cycle, the instance will run with the increased number of CPU cores within the selected period or cycle, and automatically scale in outside the selected period or cycle.
Manually disabling scale-out
After Elastic CPU scale-out > Custom scale-out is enabled, if the scale-out time is set to now, when the business does not require more CPU resources, the user needs to manually disable the CPU elastic scaling feature. Otherwise, the billing will continue.
For how to enable or disable custom scale-out, see Setting Automatic Scale-out.
Description of the Number of Cores for Automatic Scale-Out and Custom Scale-Out
The default number of CPU cores for automatic scale-out is set to be double the original number of CPU cores for the instance and cannot be modified. For example, if the original number of CPU cores for the instance is 4 cores, 4 cores will be added for scale-out, resulting in a total number of 8 cores after scaling.
CPU cores for the custom scale-out feature support scale-out units of 1 core, with a maximum limit set at double the original number of CPU cores for the instance. For example, if the original instance specification has 4 CPU cores, the cores for scale-out can be set to 5, 6, 7, or 8 cores.
Whether automatic scaling or custom scaling is used, the original number of CPU cores of an instance cannot exceed 32. For example, if the original specification of the instance is 48 cores and 480 GiB of memory, the CPU elastic scaling feature is not supported.
Billing Instructions
For billing details about the CPU elastic scale-out feature, see Billing Instructions.
Event Alarm Description
For automatic scaling and custom scaling, you can set up event alarms and configure alarm notifications. The following are the event metrics and descriptions for CPU elastic scaling.
Scaling Type
Event Metric
Description
Automatic scaling
ExpandCpuSucceeded
CPU elastic scale-out succeeded.
﻿
ExpandCpuFailed
CPU elastic scale-out failed.
﻿
ContractCpuSucceeded
CPU elastic scale-in succeeded.
Custom scaling
ExpandCpuSucceeded
CPU elastic scale-out succeeded.
﻿
ExpandCpuFailed
CPU elastic scale-out failed.
﻿
ContractCpuSucceeded
CPU elastic scale-in succeeded.
There are two reasons for automatic scaling failure and custom scaling failure: insufficient Tencent Cloud account balance or insufficient host CPU resources (which has a very low probability). If scale-out fails due to insufficient account balance, the user can top up the account and try again. For other reasons, submit a ticket for feedback.
For the steps to set event alarms, see Activating Event Alarm.
Feature Impact Description
The CPU elastic scaling feature takes effect on both the primary node and the secondary node simultaneously. If an HA switch occurs for the high-availability instance after the feature takes effect, the node after the switch will also use the scaled-out CPU specifications. After automatic scale-in is enabled or custom scale-out is disabled, the node will automatically scale in to the original CPU specification.
The feature needs to be enabled separately for read-only instances, which are not scaled out simultaneously. After the elastic CPU scaling feature is enabled and triggered for the primary instance, the CPU specification used by the read-only instances mounted to the primary instance will not be scaled out simultaneously. The CPU elastic scaling feature needs to be enabled for each read-only instance separately.
If the CPU elastic scaling feature has been enabled for an instance and the instance needs modifying instance configuration, note that the feature will be disabled after the adjustment is completed. Promptly monitor whether the CPU meets business needs after adjustment. If you want to use the feature again, re-enable it.
FAQs
1. After enabling the automatic scale-out feature of CPU elastic scaling, how do I determine whether automatic scale-out is effective?
When the average value of the instance's monitoring metric CPU utilization reaches the set automatic scale-out threshold, the instance will be automatically scaled out. You can check whether it takes effect in the instance configuration on the instance details page. If the actual number of cores is additionally displayed after the number of CPU cores in the specification, it means that the scale-out is in effect. As shown in the figure below, 1 (2) cores indicate that the current instance has already been automatically scaled out to 2 cores.
﻿
Additionally, you can view the CPU elastic scaling records of the instance in the task list. For details, see Query Scaling Tasks.
2. Will the execution of a CPU elastic scaling task interrupt the connection to the instance?
In the CPU elastic scaling feature, both scale-out and scale-in operations merely modify the instance configuration information in the management system and will not cause any impact on the instance.
3. After the CPU elastic scaling operation succeeds, do the statistics of the monitoring metric CPU utilization change?
After CPU elastic scaling, the total number of CPU cores of the instance is the sum of the CPU core number in the purchased specification and the CPU core number from elastic scaling. For example, if the instance specification is 2 cores and 4 GiB of memory, and 2 cores are added through automatic scaling, the total number of CPU cores of the instance is 4. The monitoring metric CPU utilization uses the total number of CPU cores of the instance for statistics.

Setting Automatic Scale-Out

Last updated：2025-11-20 09:44:41

This document introduces operations related to setting automatic scale-out.
Prerequisites
The computing specification of the instance before the CPU elastic scaling feature is enabled should be less than or equal to 32 cores.
Your Tencent Cloud account should have a sufficient balance to support scale-out.
The underlying machine supports scale-out. If scale-out is not supported for the underlying machine, the operation of setting automatic scale-out will fail.
Billing Instructions
For details about automatic scale-out billing information, see Billing Instructions.
Enabling Automatic Scaling
Note:
After automatic scale-out is enabled, there is a very low probability that the feature will fail to be triggered. The backend will retry multiple times until the operation is successful.
Automatic scaling is performed by continuously monitoring the CPU utilization metric. To avoid frequent scale-out and scale-in, it is recommended to set reasonable scale-out and scale-in rules.
1. Log in to the PostgreSQL console. In the Instance List, and click Instance ID or Manage in the Operation column to enter the Instance Details page.
2. Choose Instance Details > Configuration Info > Elastic CPU scale-out, and click Enable.
﻿
3. In the Elastic CPU scale-out window, complete the following configurations. Confirm the scaling cost and click OK.
﻿
Parameter
Description
Scale-Out Method
Automatic scale-out and custom scale-out are supported. Select automatic scale-out here.
Automatic scale-out: Perform a quick elastic scale-out operation based on performance to adapt to traffic peaks, and perform scale-in when traffic drops.
Custom scale-out: Perform scale-out during a custom time period or cycle, and automatically perform CPU scale-in during other periods.
Number of cores for Scale-Out
The default value is consistent with the number of CPU cores of the current instance specification. For example, if the current instance specification is 2 cores and 4 GiB of memory, the number of cores for scale-out will also be 2 cores. After scale-out is successfully triggered, the CPU of the instance will be 4 cores.
Scale-Out Rule
Set the observation period and threshold for triggering scale-out.
Observation period: Supported options are 1 minute, 3 minutes, 5 minutes, 10 minutes, 15 minutes, and 30 minutes.
Threshold: Supported options include 40%, 50%, 60%, 70%, 80%, and 90%.
The system will automatically monitor the CPU utilization metrics during the observation period. When the set threshold is reached, a CPU scale-out operation will be initiated.
Scale-In Rule
Set the observation period and threshold for triggering scale-in.
Observation period: Supported options include 5 minutes, 10 minutes, 15 minutes, and 30 minutes.
Threshold: Supported options include 10%, 20%, and 30%.
The system will automatically monitor the CPU utilization metrics during the observation period. When the set threshold is reached, a CPU scale-in operation will be initiated.
4. After automatic scaling is enabled successfully, the interface is as shown in the figure below.
﻿
Modifying the Elastic Scale-out Policy for CPU
After CPU elastic scaling is enabled, the CPU elastic scaling method and corresponding policy can be modified. The modifications take effect immediately, and the system will execute according to the new CPU elastic scaling policy.
1. Log in to the PostgreSQL console. In the Instance List, and click Instance ID or Manage in the Operation column to enter the Instance Details page.
2. Choose Instance Details > Configuration Info > Elastic CPU scale-out, and click Modify.
﻿
Disabling Automatic Scaling
Note:
Note: After automatic scale-out is disabled, the CPU cores after scale-out will be immediately scale-in to the number before instance scale-out. After scale-in, scale-out will not be performed based on the scale-out threshold.
1. Log in to the PostgreSQL console. In the Instance List, and click Instance ID or Manage in the Operation column to enter the Instance Details page.
2. Choose Instance Details > Configuration Info > Elastic CPU scale-out, and click Disable.
﻿
3. Click OK in the pop-up window of Stop CPU Scale-Out.
﻿

Setting Custom Scale-Out

Last updated：2025-11-20 09:44:42

This document introduces operations related to setting custom scale-out.
Prerequisites
The computing specification of the instance before the CPU elastic scaling feature is enabled should be less than or equal to 32 cores.
Your Tencent Cloud account should have a sufficient balance to support CPU scale-out.
Billing Instructions
For details about automatic scale-out billing information, see Billing Instructions.
Enabling Custom Scale-Out
Note:
After custom scale-out is enabled, there is a very low probability of failing to initiate scale-out during the time period or cycle. The backend will retry multiple times until the initiation succeeds.
1. Log in to the PostgreSQL console. In the Instance List, click Instance ID or Manage in the Operation column to enter the instance details page.
2. Choose Instance Details > Configuration Info > Elastic CPU scale-out, and click Enable.
﻿
3. In the Elastic CPU scale-out window, set the scale-out method, number of cores for scale-out, and scale-out time, and then click OK.
﻿
Scale-Out Method: Automatic scaling and custom scaling are supported. Select Custom scale-out here.
Automatic scale-out: Perform a quick elastic scale-out operation based on performance to adapt to traffic peaks, and perform scale-in when traffic drops.
Custom scale-out: Perform scale-out during a custom time period or cycle, and automatically perform CPU scale-in during other periods.
Number of Cores After Scale-out: Set the number of additional CPU cores to be added. Scale-out by 1 core increments is supported, with the maximum number of additional cores being 1 times the number of cores of the current CPU specification. For example, an instance with 8 cores and 16 GiB of memory can be scaled out to a maximum of 8 additional cores.
Scale-out time: supports Now, By period, and By cycle. Select one for configuration based on actual needs.
Now
﻿
Scale-out time: Select Now to trigger scale-out immediately after the feature is successfully enabled. After scale-out, automatic scale-in is not supported. You need to manually disable scale-out, then it can immediately scale-in to the original CPU core number.
By Period
﻿
Scale-out time: Select By period to enable and trigger scale-out during the selected period, with automatic scale-in to the original CPU core number outside the time period.
By Cycle
﻿
Scale-out time: Select By cycle to enable and trigger scale-out based on the selected time cycle, with automatic scale-in to the original CPU core number outside the time period.
4. When the instance status changes from Modifying to Running, the feature is enabled successfully.
Modifying the Elastic Scale-Out Policy for CPU
After CPU elastic scaling is enabled, the CPU elastic scaling method and corresponding policy can be modified. The modifications take effect immediately, and the system will execute according to the new CPU elastic scaling policy.
1. Log in to the PostgreSQL console. In the Instance List, click Instance ID or Manage in the Operation column to enter the instance details page.
2. Choose Instance Details > Configuration Info > Elastic CPU scale-out, and click Modify.
﻿
Disabling Custom Scale-Out
Note:
Once the feature is disabled, the elastic scale-out is unavailable for the current instance.
1. Log in to the PostgreSQL console. In the Instance List, and click Instance ID or Manage in the Operation column to enter the Instance Details page.
2. Choose Instance Details > Elastic CPU scale-out, and click Disable.
﻿
3. Click OK in the pop-up window of Stop CPU Scale-Out.
﻿

Enabling Event Alarms

Last updated：2025-11-20 09:44:42

TencentDB for PostgreSQL supports the event alarm feature. If the user sets event alarms related to CPU elastic scaling and configures alarm notifications, when events such as scale-out triggering, scale-out failure, and scale-in are detected, event alarm notifications will be sent through various optional channels to the user. This document introduces how to set up event alarms related to CPU elastic scaling.
Scenarios
Users can create event alarms to trigger alarms and send related messages when status changes (such as CPU elastic scale-out success, CPU elastic scale-out failure, and CPU elastic scale-in success) occur after the elastic scaling feature is enabled in TencentDB for PostgreSQL.
Operation Steps
Creating an Alarm Policy
1. Log in to the Tencent Cloud Observability Platform console, and choose Alarm Management > Alarm Configuration in the left sidebar.
2. On the alarm policy page, select Cloud Product Monitoring as the monitoring type and click Create Policy.
3. On the policy creation page, complete the settings for basic information, alarm rules, and alarm notifications.
Policy Type: Choose Cloud Database > PostgreSQL.
Alarm Object: You can find the object instance that needs to be associated by selecting the region where the object is located or searching for the instance ID of the object.
Trigger Condition: Find event alarms, click Add Event, and add CPU performance scale-out, CPU performance scale-out failure, and CPU performance scale-in alarm events respectively.
﻿
Configure alarm notification: You can select a preset or user-defined notification template. For custom notification templates, see Creating Notification Template.
Select a system preset template.
﻿
Create a template.
﻿
4. After confirmation, click Complete.
Associating an Alarm Object
After creating an alarm policy, you can also associate it with other alarm objects (instances that require alarms related to the CPU performance scaling). When the object meets the alarm trigger condition, an alarm will be sent.
1. On the Alarm Policy page, click the Policy Name to enter the alarm policy management page.
2. On the Alarm Object section of the alarm policy management page, click Add Object.
﻿
3. In the pop-up dialog box, select the alarm object to be associated with, and click OK to associate the alarm object.

Querying Effective Scaling Tasks

Last updated：2025-11-20 09:44:42

TencentDB for PostgreSQL supports querying effective CPU scaling tasks of instances, convenient for you to learn about the instance's CPU scaling status. This document introduces how to query historical scaling tasks.
Prerequisites
The CPU elastic scaling feature has been enabled for the instance, and scaling records with actual effectiveness have been generated.
Operation Steps
1. Log in to the PostgreSQL console and click Task List.
2. Search for the instance ID in the task list and view all tasks of the instance.
﻿
3. Choose Operation > Task Details to view scaling details.
For CPU elastic scale-out tasks, the ExpandCpu field in the task's input information is 0 cores, and the ExpandCpu field in the output information is the actual number of scaled cores.
﻿
For CPU elastic scaling-in tasks, the ExpandCpu field in the task's input information is the actual number of scaled-in cores, and the ExpandCpu field in the output information is 0 cores.
﻿

Billing Instructions

Last updated：2025-11-20 09:44:42

This document introduces the billing for CPU elastic scaling.
Automatic Scaling Billing Instructions
﻿
After enabling Elastic CPU scale-out > Automatic scale-out, fees are charged based on the number of scaled CPU cores when elastic scale-out is successfully triggered. No additional fees are charged if no scaling is performed.
Automatic scaling is performed by continuously monitoring the CPU utilization metric. To avoid frequent scale-out and scale-in, it is recommended to set reasonable scale-out and scale-in rules.
Billing Formula
When the method of the CPU elastic scaling feature is automatic scaling, the fees are charged in Pay-as-You-Go mode on a minute basis and are deducted once per hour.
Billing formula = (Single-replica single-core fee x Additional CPU cores per replica x Number of replicas) x Scaling duration (minutes) / 60.
Automatic Scaling Billing Example
Example 1
For a high-availability instance in the Guangzhou region with a CPU specification of 4 cores, its CPU increases to 8 cores, with a scaling duration of 1 hour after automatic performance scaling is triggered. The unit price in the Guangzhou region is 0.27 USD/core/hour. The billing formula is 0.27 (unit price) x 4 (additional CPU cores) x 2 (number of replicas) x 1 (scaling duration) = 2.16 USD.
Example 2
For a read-only instance in the Guangzhou region with a CPU specification of 2 cores, its CPU increases to 4 cores, with a scaling duration of 30 minutes after automatic performance scaling is triggered. The unit price in the Guangzhou region is 0.27 USD/core/hour. The billing formula is 0.27 (unit price) x 2 (additional CPU cores) x 1 (number of replicas) x 30/60 (scaling duration) = 0.27 USD.
Custom Scale-Out Billing Instructions
﻿
Billing Formula
When the method of the CPU elastic scale-out feature is custom scale-out, the fees are charged in Pay-as-You-Go mode on a minute basis and are deducted once per hour.
Billing formula = (Single-replica single-core fee x Additional CPU cores per replica x Number of replicas) x Scaling duration (minutes) / 60.
Scale-Out Time Selection and Billing Instructions
When the scaling time is set to now, the feature takes effect immediately and triggers scale-out after being enabled, with fees being charged synchronously until you disable the scale-out. For how to disable scale-out, see Setting Automatic Scale-out. For a billing example, see Example 1.
When the scaling time is by period or cycle, the feature takes effect and triggers scale-out according to the selected period or cycle after being enabled, and billing starts synchronously after successful scaling. No fees are charged in other periods or cycles. For billing examples, see Example 2 and Example 3.
Custom Scale-Out Billing Example
Example 1
A high-availability instance in the Beijing region has a CPU specification of 2 cores. At 10:00 AM, CPU elastic scaling mode was enabled for the instance. The mode was custom scaling, and the scaling time was Now, with 2 additional CPU cores. At 5:00 PM, CPU elastic scaling was disabled, resulting in a scaling duration of 7 hours. The unit price in the Beijing region is 0.27 USD/core/hour. The billing for this custom scaling of this instance is: 0.27 (unit price) × 2 (additional CPU cores) × 2 (number of replicas) × 7 (scaling duration) = 7.56 USD.
Example 2
A high-availability instance in the Beijing region has a CPU specification of 2 cores. CPU elastic scaling was enabled for the instance. The mode was custom scaling, the number of additional cores was 2, and scaling time was By period, with a start time of 00:00 on May 1, 2025, and an end time of 00:00 on May 15, 2025. The billing for custom scaling of this instance in May 2025 is: 0.27 (unit price) x 2 (additional CPU cores) x 2 (number of replicas) x 360 (scaling duration) = 388.8 USD.
Example 3
A high-availability instance in the Beijing region has a CPU specification of 2 cores. The CPU elastic scaling was enabled for the instance on April 30, 2025. The mode was custom scaling, and scaling time was By cycle, with 2 additional CPU cores. The cycle was from Monday to Friday, and the start time and end time were from 00:00 to 00:00. The CPU elastic scaling policy was not changed until May 31. The billing for the custom scaling price of this instance in May 2025 is: 0.27 (unit price) x 2 (number of additional CPU cores) x 2 (number of replicas) x 528 (scaling duration) = 570.24 USD.

Read-Only Instance

Overview

Last updated：2025-09-11 15:27:47

TencentDB for PostgreSQL allows you to create one or more read-only instances. They are suitable for read/write separation and one-primary-multiple-standby application scenarios and capable of greatly enhancing the read load capacity of your database.
Unified read/write separation addresses (i.e., read and write requests are separated automatically) are not supported currently. You can access read-only instances with separate IPs and ports, or add them to a read-only instance group (RO group) to balance their loads.
Note: 
For read-only instance fees, see Product Pricing.
You can create 1 read-only instance each time, with a maximum of 6 read-only instances.
You can configure at least two read-only instances to avoid business access failure caused by a single-point fault.
Read-only instances do not have high-availability capabilities. It is recommended to use a read-only instance group. A read-only group with only one read-only instance has a single-point risk and will not be included in the overall availability calculation of the TencentDB for PostgreSQL service. A single read-only instance does not provide an SLA availability guarantee. It is recommended to select at least two read-only instances in the read-only group to ensure its availability.
Concepts
RO group: It consists of one or more load balancing-enabled read-only instances. If there are multiple read-only instances in one RO group, read requests can be evenly distributed among the instances. RO groups provide IPs and ports for access to databases.
Read-only instance: It is a single-node (with no standby) instance that supports read requests. It cannot exist independently; instead, it must belong to a primary instance.
Architecture
Changes in the primary instance (source database) are synced to all read-only instances through PostgreSQL's streaming replication mechanism. Given the single-node architecture (with no standby) of read-only instances, repeated attempts to restore a failed read-only instance will be made. Therefore, we recommend you choose an RO group rather than a read-only instance for higher availability.
﻿
Feature Limits
The minimum disk capacity of a read-only instance must be greater than or equal to the storage capacity used by the primary instance.
Up to six read-only instances can be created for a primary instance.
Backup and rollback features are not supported.
Data cannot be migrated to read-only instances.
Databases cannot be created in or deleted from read-only instances.
Operations including account creation/deletion/authorization and account name/password modification are not supported.
Notes
There is no need to maintain accounts or databases for read-only instances, which are synced with those of the primary instance.
Data inconsistency between multiple read-only instances may occur due to the delay in data sync between the read-only instances and the primary instance. You can check the delay in the console and configure CM alarms.
The specification of a read-only instance can be different from that of the primary instance, which makes it easier for you to upgrade the read-only instance based on your business load. We recommend you keep the same specifications of read-only instances in one RO group.
If the primary instance is written so frequently that the automatic log cleanup threshold is exceeded, logs will be automatically deleted. If the standby instance hasn't obtained the deleted logs yet, the primary-standby replication will be disconnected, and the read-only instance will be automatically rebuilt and become inaccessible.
Read-only instances don't have high availability. We recommend you use an RO group and configure at least two read-only instances to avoid business access failures caused by single points of failures.
Directions
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an Instance ID or Manage in the Operation column to enter the instance management page.
2. Click Add Read-Only Instance in the Instance Architecture Diagram section on the Instance Details tab or click Create on the Read-only Instance tab.
﻿
﻿
3. On the purchase page, select the desired read-only instance configuration, confirm that everything is correct, and click Buy Now.
Specify RO Group: Select Create RO group, or Existing RO group.
Create RO group: If multiple read-only instances are purchased at a time, all of them will be assigned to the newly created RO group. The RO group automatically allocates read weights to each read-only instance and automatically distributes read requests among them based on their read weights. For more information, see Managing RO Groups.
Existing RO group: Specify an existing RO group. If multiple read-only instances are purchased at a time, all of them will be assigned to the RO group.
Remove Delayed RO Instances: Remove a read-only instance from the RO group if the data sync log size difference between the primary instance and the read-only instance is greater than the specified threshold (in MB).
AZ: You can select any AZ in the same region as the primary instance.
4. After the purchase is completed, you will be redirected to the instance list. After the status of the instance changes to Running, the instance can be used normally.

Managing RO Groups

Last updated：2025-09-10 22:02:23

TencentDB for PostgreSQL allows you to create one or more read-only instances to form an RO group, which is suitable for read/write separation and one-primary-multiple-standby application scenarios. This greatly improves the read load capacity of your database.
Prerequisites
You have created a primary instance. For more information, see Purchase Methods.
You have created a read-only instance. For more information, see Overview.
Creating RO Group
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click More > Create Read-Only Instance in the Operation column of the target instance to enter the instance purchase page.
﻿
Note: 
You can also click an Instance ID or Manage in the Operation column to enter the instance management page.
Click Add Read-Only Instance in the Instance Architecture Diagram section on the Instance Details tab to enter the read-only instance purchase page.
Or, click Create on the Read-Only Instance tab to enter the read-only instance purchase page.
﻿
2. On the purchase page, select the desired read-only instance configuration, confirm that everything is correct, and click Buy Now.
Specify RO Group: Select Create RO Group. If multiple read-only instances are purchased at a time, all of them will be assigned to the newly created RO group. The RO group automatically allocates read weights to each read-only instance and automatically distributes read requests among them based on their read weights.
RO Group Name: The RO group name doesn't need to be unique and can contain up to 60 letters, digits, hyphens, and underscores.
Remove Delayed RO Instances: This option indicates whether to enable the removal policy. A read-only instance will be removed from the RO group when its delay exceeds the threshold, and will rejoin the RO group when its delay drops below the threshold. A removed read-only instance will become inactive, its weight will be set to 0 automatically, and warning notifications will be sent. For more information on how to configure read-only instance removal alarms and recipients, see Alarming Feature.
 No matter whether delayed read-only instance removal is enabled, a read-only instance that is removed due to instance failure will rejoin the RO group when it is repaired.
Delay: This sets the delay time for a read-only instance. When the threshold is exceeded, the instance will be removed from the RO group.		
Delay Threshold: This sets the delay threshold for a read-only instance. When the data sync log size difference between the primary instance and the read-only instance is above the threshold, the read-only instance will be removed from the RO group.
Least RO Instances: This is the minimum number of instances that should be retained in the RO group. When there are fewer instances in the RO group, even if an instance exceeds the delay threshold, it will not be removed.
﻿
3. Return to the instance list. The status of the created instance is Delivering. After the status changes to Running, the read-only instance has been successfully created.
Note：
When a read-only instance is associated with the primary instance of a PostgreSQL database, certain parameters on the read-only instance must be set to values equal to or greater than those on the primary node. Otherwise, the read-only instance will fail to start properly. For example, parameters such as `max_connections`, `max_worker_processes`, and `max_wal_senders`. During the creation of a read-only instance, if the selected specifications cannot meet the requirement that the parameter values of the read-only instance are equal to or greater than those of the primary instance, a corresponding prompt will be displayed, as shown in the figure below:
﻿
Configuring RO Group
On the RO group configuration page, you can configure the basic information of the group such as name, removal policy, delay threshold, and least read-only instances.
Note: 
Read-only instances in an RO group can have different specifications, and read weights are automatically assigned by the system according to instance specifications.
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click a primary instance ID to enter the instance management page.
2. On the instance management page, click the Read-Only Instance tab and click Configuration in the Operation column to enter the RO group configuration page.
﻿
3. On the RO group configuration page, configure the RO group and click Submit.
Assign Read Weight: The traffic of each read-only instance in an RO group will be automatically distributed according to its read weight, which can implement load balancing and reduce the difficulty in managing multiple read-only instance IP addresses. An RO group automatically assigns read weights to each read-only instance. The following table lists the read weights of read-only instances of different specifications:
Specification
Weight
2 GB memory
1
4 GB memory
2
8 GB memory
2
12 GB memory
4
16 GB memory
4
24 GB memory
8
32 GB memory
8
48 GB memory
10
64 GB memory
12
96 GB memory
14
128 GB memory
16
240 GB memory
26
480 GB memory
50
Rebalance:
If rebalancing is disabled, modifying weight will only affect new loads. The operation has no impact on read-only instances accessed by existing persistent connections and does not cause momentary database disconnections.
If rebalancing is enabled, when the configurations of read-only instances in the RO group are modified, all connections to the RO group will be disconnected, and new connections will be rebalanced according to instance weights.
﻿
Deleting RO Group
An RO group can be deleted if it has no read-only instances.
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click a primary instance ID to enter the instance management page.
2. On the instance management page, select the Read-Only Instance tab to view all RO groups. You can delete an RO group after confirming that there are no read-only instances in it.
﻿

Removal Policy and Load Balancing

Last updated：2024-01-24 11:16:51

TencentDB for PostgreSQL allows you to create one or more read-only replicas to form a read-only replica group (RO group), which is suitable for read/write separation and one-primary-multiple-secondary application scenarios and capable of greatly enhancing the read load capacity of your databases. This document describes how to manage RO groups.
Rebalancing Traffic
If load rebalancing is disabled, modifying weight will take effect only for new loads but not affect the read-only replicas accessed by existing persistent connections or cause short disconnection from the database.
If load rebalancing is enabled, the read weights of upgraded read-only replicas will change, which causes all connections to the RO group to be disconnected after the upgrade is completed, and all new connections will be rebalanced according to the new weights.
If you are not satisfied with the connection distribution of each read-only replica in the RO group, you can also manually rebalance it: log in to the console, click the primary instance ID to access the instance management page, select the Read-only Replica tab, locate the desired read-only replica in the RO group, and click Rebalance in the Operation column.
Note: 
Make sure your business has an automatic reconnection mechanism. Neither enable automatic rebalancing nor manually rebalance if there is no automatic reconnection mechanism.
Removing Failed Read-only Replicas
When a read-only replica in a RO group becomes inaccessible due to an unexpected error, the RO group automatically removes the read-only replica. This rule is a default rule.
Removing Delayed Read-only Replicas
If this feature is enabled, a read-only replica will be removed from the RO group if the data sync log size difference between the primary instance and the read-only replica is greater than the specified threshold (MB).
Allocating Read Weights
The traffic of each read-only replica in an RO group will be automatically distributed according to its read weight, which can realize load balancing and reduce the difficulty of managing multiple read-only replica IP addresses. An RO group automatically allocates read weights to each read-only replica. The following table lists the read weights of read-only replicas of different specifications:
Specification
Weight
2 GB memory
1
4 GB memory
2
8 GB memory
2
12 GB memory
4
16 GB memory
4
24 GB memory
8
32 GB memory
8
48 GB memory
10
64 GB memory
12
96 GB memory
14
128 GB memory
16
240 GB memory
26
480 GB memory
50
References
For more information on how to create one or more read-only replicas, please see Creating Read-only Replicas.
For more information on how to create one or more read-only replicas and add them to an RO group, please see Managing RO Groups.

Account Management

Database Privilege Overview

Last updated：2024-01-24 11:16:51

Account Privilege System
PostgreSQL adopts a role-based access control (RBAC) model to manage users, roles, and permissions.
In PostgreSQL, the concepts of users and roles are almost the same. The only difference is that a user has the login privilege, while a role has the nologin privilege.
PostgreSQL supports system permissions and database object permissions, and manages them using the concept of roles. Both categories of the permissions can be granted to a role, and this role can grant its own permissions to other roles or users.
You can grant system or object permissions to roles/users to manage databases.
System Permissions
System permissions are used to perform database operations. PostgreSQL manages system permissions using role attributes and default roles.
Role attributes
You can specify attributes when creating a role with CREATE ROLE, or modify them after creation with ALTER ROLE. Role attributes are stored in the pg_authid system table.
CREATE ROLE syntax:
CREATE ROLE name [ [ WITH ] option [ ... ] ]
where option can be:
      SUPERUSER | NOSUPERUSER
    | CREATEDB | NOCREATEDB
    | CREATEROLE | NOCREATEROLE
    | INHERIT | NOINHERIT
    | LOGIN | NOLOGIN
    | REPLICATION | NOREPLICATION
    | BYPASSRLS | NOBYPASSRLS
    | CONNECTION LIMIT connlimit
    | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL
    | VALID UNTIL 'timestamp'
    | IN ROLE role_name [, ...]
    | IN GROUP role_name [, ...]
    | ROLE role_name [, ...]
    | ADMIN role_name [, ...]
    | USER role_name [, ...]
    | SYSID uid
A role with the superuser attribute can bypass all privilege checks and perform all database operations, because a superuser has the highest privilege in the database, which is similar to the root privilege in Linux.
Note: 
 TencentDB for PostgreSQL has disabled the superuser privilege due to security requirements. However, some operations must be performed by a superuser, so TencentDB for PostgreSQL provides the tencentdb_superuser role. For details, see Roles and Permissions.
Default roles
PostgreSQL provides a set of default roles which provide access to certain, commonly needed, privileged capabilities and information. Administrators can grant these roles to users and/or other roles in their environment, providing those users with access to the specified capabilities and information. The following table lists the default roles supported in PostgreSQL 11.
Role
Allowed Access
pg_execute_server_program
Allow executing programs on the database server as the user the database runs as with COPY and other functions which allow executing a server-side program.
pg_monitor
Read/Execute various monitoring views and functions. This role is a member of pg_read_all_settings, pg_read_all_stats, and pg_stat_scan_tables.
pg_read_all_settings
Read all configuration variables, even those normally visible only to superusers.
pg_read_all_stats
Read all pg_stat_* views and use various statistics related extensions, even those normally visible only to superusers.
pg_read_server_files
Allow reading files from any location the database can access on the server with COPY and other file-access functions.
pg_signal_backend
Signal another backend to cancel a query or terminate its session.
pg_stat_scan_tables
Execute monitoring functions that may take ACCESS SHARE locks on tables, potentially for a long time.
pg_write_server_files
Allow writing to files in any location the database can access on the server with COPY and other file-access functions.
public
An implicitly defined group that always includes all roles. Any particular role will have the sum of permissions granted directly to public. PostgreSQL grants default  permissions on some types of objects to public.
Database Object Permissions
PostgreSQL uses an access control list (ACL) to manage database object  permissions. The following table lists all database object permissions in PostgreSQL and their abbreviations.
Permissions
Abbreviation
Supported Object
SELECT
r ("read")
LARGE OBJECT, SEQUENCE, TABLE (and table-like objects), table column
INSERT
a ("append")
TABLE, table column
UPDATE
w ("write")
LARGE OBJECT, SEQUENCE, TABLE, table column
DELETE
d
TABLE
TRUNCATE
D
TABLE
REFERENCES
x
TABLE, table column
TRIGGER
t
TABLE
CREATE
C
DATABASE, SCHEMA, TABLESPACE
CONNECT
c
DATABASE
TEMPORARY
T
DATABASE
EXECUTE
X
FUNCTION, PROCEDURE
USAGE
U
DOMAIN, FOREIGN DATA WRAPPER, FOREIGN SERVER, LANGUAGE, SCHEMA, SEQUENCE, TYPE
The following table lists the  permissions owned by a type of objects and the psql command to query the permissions:
Object Type
Permissions
Permissions of Default Role (public)
psql Command to Query Permissions
DATABASE
CTc
Tc
\l
DOMAIN
U
U
\dD+
FUNCTION or PROCEDURE
X
X
\df+
FOREIGN DATA WRAPPER
U
none
\dew+
FOREIGN SERVER
U
none
\des+
LANGUAGE
U
U
\dL+
LARGE OBJECT
rw
none
-
SCHEMA
UC
none
\dn+
SEQUENCE
rwU
none
\dp
TABLE (and table-like objects)
arwdDxt
none
\dp
Table column
arwx
none
\dp
TABLESPACE
C
none
\db+
TYPE
U
U
\dT+
In PostgreSQL, the permissions granted for a particular object are displayed as a list of aclitem entries. The aclitem list of database and schema permissions is stored in pg_database.datacl and pg_namespace.nspacl, that of permissions for tables, views, and other objects stored in pg_class.relacl, and that of column permissions stored in pg_attribute.attacl.
For example, "normal_user=a*r/test1" specifies that the user normal_user has the privilege INSERT with grant option (which gives the user the right to grant the privilege to others) and the privilege SELECT, both granted by test1.
postgres=# \dp
                            Access privileges
 Schema | Name | Type  | Access privileges | Column privileges | Policies
--------+------+-------+-------------------+-------------------+----------
 public | t1   | table | test1=arwdDxt/test1 |                   |
(1 rows)
postgres=# grant select on t1 to normal_user;
GRANT
postgres=# grant insert on t1 to normal_user with grant option;
GRANT
postgres=# grant update on t1 to public;
GRANT
postgres=# grant select (a) on t1 to test2;
GRANT
postgres=# \dp
                              Access privileges
 Schema | Name | Type  |  Access privileges    | Column privileges | Policies
--------+------+-------+-----------------------+-------------------+----------
 public | t1   | table | test1=arwdDxt/test1  +| a:               +|
        |      |       | normal_user=a*r/test1+|   test2=r/test1   |
        |      |       | =w/test1              |                   |
(1 rows)
-- Where, "=w/test1" specifies that test1 grants public the UPDATE privilege.
﻿

Users and Permission Operations

Last updated：2024-01-24 11:16:51

TencentDB Default Role
TencentDB for PostgreSQL does not open the superuser role attribute and the pg_execute_server_program, pg_read_server_files, and pg_write_server_files roles for you to use. However, as some operations require the superuser role, TencentDB for PostgreSQL provides the pg_tencentdb_superuser to replace superuser.
pg_tencentdb_superuser Role
This role supports system permissions and database object permissions, as listed in the following tables.
System permissions
Permission
Description
CREATEDB
Create a database.
BYPASSRLS
Bypass all row-level security policy checks.
REPLICATION
Have the REPLICATION permission by default, and allow granting the REPLICATION permission to other users.
CREATEROLE
Have the same CREATEROLE permission as the community edition, except that the role cannot create the pg_read_server_files, pg_write_server_files, and pg_execute_server_program roles.
Object permissions
Object
Description
database
By default, have the permissions of all databases not owned by a  a superuser.
schema
By default, have the permissions of all schemas not owned by a superuser.
table/sequence
By default, have the permissions of all tables/sequences not owned by a  a superuser.
function
By default, have the permissions of all functions not owned by a superuser.
language
No permissions.
tablespace
No permissions.
FDW/foreign server
By default, have the permissions of all FDWs/foreign servers not owned by a  a superuser.
TYPE
By default, have the permissions of all TYPEs not owned by a superuser.
Other operations
Pub/Sub: the tencentdb_superuser role can implement the pub/sub messaging paradigm, create a publication for all tables, and create slots.
Extensions: the tencentdb_superuser role can create all supported extensions. When creating an extension, the pg_tencentdb_superuser is temporarily escalated to superuser and passes all permission checks. 
The load_file permission only allows loading supported extension libraries.
The tencentdb_superuser role can use the pgstat_get_backend_current_activity function to view deadlock details, so that users can easily troubleshoot deadlocks themselves.
The use of the pg_signal_backend function is restricted, and processes of the pg_tencentdb_superuser role can only be killed by itself.
Permission Operations
For more information, see the official documents in the PostgreSQL community:
Create a user:
CREATE USER name [ [ WITH ] option [ ... ] ]
﻿
where option can be:
﻿
    SUPERUSER | NOSUPERUSER
  | CREATEDB | NOCREATEDB
  | CREATEROLE | NOCREATEROLE
  | INHERIT | NOINHERIT
  | LOGIN | NOLOGIN
  | REPLICATION | NOREPLICATION
  | BYPASSRLS | NOBYPASSRLS
  | CONNECTION LIMIT connlimit
  | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL
  | VALID UNTIL 'timestamp'
  | IN ROLE role_name [, ...]
  | IN GROUP role_name [, ...]
  | ROLE role_name [, ...]
  | ADMIN role_name [, ...]
  | USER role_name [, ...]
  | SYSID uid
Create a role:
CREATE ROLE name [ [ WITH ] option [ ... ] ]
﻿
where option can be:
﻿
    SUPERUSER | NOSUPERUSER
  | CREATEDB | NOCREATEDB
  | CREATEROLE | NOCREATEROLE
  | INHERIT | NOINHERIT
  | LOGIN | NOLOGIN
  | REPLICATION | NOREPLICATION
  | BYPASSRLS | NOBYPASSRLS
  | CONNECTION LIMIT connlimit
  | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL
  | VALID UNTIL 'timestamp'
  | IN ROLE role_name [, ...]
  | IN GROUP role_name [, ...]
  | ROLE role_name [, ...]
  | ADMIN role_name [, ...]
  | USER role_name [, ...]
  | SYSID uid
Modify a role attribute:
ALTER ROLE role_specification [ WITH ] option [ ... ]
﻿
where option can be:
﻿
    SUPERUSER | NOSUPERUSER
  | CREATEDB | NOCREATEDB
  | CREATEROLE | NOCREATEROLE
  | INHERIT | NOINHERIT
  | LOGIN | NOLOGIN
  | REPLICATION | NOREPLICATION
  | BYPASSRLS | NOBYPASSRLS
  | CONNECTION LIMIT connlimit
  | [ ENCRYPTED ] PASSWORD 'password' | PASSWORD NULL
  | VALID UNTIL 'timestamp'
Grant an object privilege to a role:
# Syntax example
GRANT <privilege> on <object> to <role>;
Revoke an object privilege from a role:
# Syntax example
REVOKE <privilege> ON <object> FROM <role>;
Grant a role to another role:
# Syntax example
GRANT <role name> to <another role>;
﻿

Console Operation Instructions

Last updated：2025-07-22 20:25:30

This document mainly focuses on interface-based database account operations on the console.
Creating an Account
TencentDB for PostgreSQL does not provide superuser role attributes and pg_execute_server_program, pg_read_server_files and pg_write_server_files roles for users to use. However, as some operations require superuser permissions, TencentDB for PostgreSQL offers the pg_tencentdb_superuser role as a substitute for the superuser role. For more information on pg_tencentdb_superuser, refer to User and Permission Operations.
There are two types of console accounts: pg_tencentdb_superuser accounts and ordinary accounts. Any account that is a member of the pg_tencentdb_superuser role is a pg_tencentdb_superuser account; otherwise, it is an ordinary account.
You can log in to the PostgreSQL console, and in the instance list, click Instance ID or Manage in the Operation column to go to the instance details page. Click Database Management > Account Management > Create account to initiate the creation process.
﻿
﻿
Note:
When an account is created on the console, the account name should meet the following criteria: The account name must consist of letters (a-z, A-Z), digits (0-9), and underscores (_), beginning with either a letter or an underscore (_). It can contain a maximum of 63 characters. Reserved system keywords are prohibited, and the name cannot be "postgres" or start with "pg_" or "tencentdb_".
The console only supports account creation for instances with major versions 9.5 and above. For instances below this version, please Upgrading Instance first.
Account Display
Note:
1. The console account list can display all accounts in the database instance that are in normal or locked status. These accounts can be created through the console or other clients connected to the database.
2. The console only supports the display of users, not roles.
3. Only accounts created on the console will have their creation time recorded by the management system. Be aware of this.
4. When the system permissions of an account include nologin or CONNECTION = 0, the account is in the locked status.
5. The console only supports the display of database accounts that meet the account name requirements. Be aware of this.
6. Please be informed that the modification timestamp field currently does not include records of password reset times.
Database accounts created through the console, other clients or programs can all be displayed in the account list. See the figure below for details:
﻿
Modifying an Account
Resetting the Password
You can reset the login password of an existing account on the console. If you have currently logged in to the database with the account, the reset password will be valid for subsequent connections. Click Operation > Reset Password, as shown in the figure below:
﻿
The pop-up box is shown below:
﻿
Modifying Remarks
You can modify the account remarks on the console. Click Operation > More > Modify Remarks, as shown in the figure below:
﻿
The pop-up box is shown below:
﻿
Modifying the Type
There are two types of console accounts: pg_tencentdb_superuser accounts and ordinary accounts. Any account that is a member of the pg_tencentdb_superuser role is a pg_tencentdb_superuser account; otherwise, it is an ordinary account. For more information on pg_tencentdb_superuser, refer to User and Permission Operations.
You can change the account type on the console. Click Operation > More > Modify Type, with details shown below:
﻿
The pop-up box is shown below:
﻿
Modifying Permissions
Description of Account Object Permissions
An account's object permissions consist of three parts:
Permissions inherited from roles: In PostgreSQL, a user can belong to one or more roles, and these roles can have specific permissions. For example, a role might have the permission to access a database or modify a table. If a user belongs to this role, then it will inherit all the permissions of the role.
Permissions inherited from public : As mentioned earlier, public is a special predefined group to which all users automatically belong. If a permission is granted to the public group, then all users will have the permission.
Directly granted permissions: Besides the permissions inherited from roles and public, a user can be directly granted permissions. For example, a database administrator can directly grant a user the permission to access a particular database or modify a table.
These three aspects of permissions can overlap with each other. To REVOKE a specific permission from a user, the permission should be REVOKE in all the three aspects. Granting and revoking object permissions do not apply to the OWNER. The OWNER has all permissions on an object.
Note:
The console's ability to modify permissions applies to directly granted permissions. If a permission of an account still exists after being revoked, you need to further check if the user has inherited the permission from the public group or is the OWNER of the object.
On the console, you can grant or revoke multiple different permissions for multiple objects for an account, or grant or revoke multiple different permissions for multiple objects of the same category for an account in bulk.
Granting or Revoking Multiple Different Permissions for Multiple Objects for an Account
Click Operation > Modify Permissions. The pop-up box is as follows:
﻿
The pop-up box is as follows:
Note:
Since account permissions can be modified through multiple clients or programs, it is strongly recommended that you click the Refresh button each time before operating permissions on the Console to retrieve the latest permissions.
﻿
Note:
public is a special predefined group to which all users automatically belong. When permissions are granted to the public group, they are actually granted to all users, including existing and future users.
If a certain permission of an object is already possessed by the public group, to revoke the permission, you should remove it from the public group for the revocation to take effect.
Once a permission is revoked from the public group, all users will lose the permission, so operate with caution.
To help you quickly revert to the initialization state after an erroneous click, click the Reset button. This will restore all interface operations to the current account permission status, allowing you to reoperate on this basis.
Click OK. The system will summarize all the permission operations you are about to initiate for the currently selected account, so as to facilitate your second confirmation. Details are shown in the figure below:
﻿
As shown above, this account's permission modification operations involve two databases: nomal_1 and db_priv, with details shown below:
1. Operations on the nomal_1 database involve the following three aspects:
1.1 A REVOKE TEMPORARY operation is performed on the nomal_1 database.
1.2 A REVOKE INSERT operation is performed on the id field of the amyttt table in the sche_priv schema.
1.3 A REVOKE UPDATE operation is performed on the am_s sequence in the sche_priv schema.
2. A REVOKE CREATE operation is performed on the db_priv database.
Granting or Revoking Multiple Different Permissions for Multiple Objects of the Same Category for an Account
When you need to handle multiple permissions for objects of the same category for an account simultaneously, you can use the Batch Authorize/Deauthorize feature. The pop-up box is as follows:
﻿
Note:
The batch authorization/revocation feature is designed for performing bulk operations on a single account for the same type of object. It does not support batch operations that simultaneously involve both databases and schemas.
In bulk mode, the display of authorized status is not supported because permissions may vary. Operate with caution.
Deleting an Account
When you no longer need a certain database account, the console supports the deletion operation. Click Operation > More > Delete Account, with details shown below:
﻿
An account can be deleted only when it has no object permissions; otherwise, an error will be reported when the account is deleted, as shown in the figure below:
﻿
If an error is reported when a database account is deleted, we can check whether the account has permissions on certain objects or is the OWNER of certain objects. If so, revoke the corresponding permissions or replace the object's OWNER before proceeding with the deletion of the account.
In PostgreSQL, aclitem is used to represent permissions on a specific database object. For a detailed explanation, refer to the Overview of Database Permissions.
Methods to check whether an account has permissions on certain objects are as follows:
(1) To check whether the account has permissions on certain databases, refer to the following command:
  nomal_1=> select datname,datacl from pg_database;
  datname  |                                 datacl                                 
-----------+------------------------------------------------------------------------
 template1 | {=c/postgres,postgres=CTc/postgres}
 template0 | {=c/postgres,postgres=CTc/postgres}
 postgres  | {=Tc/postgres,postgres=CTc/postgres,pg_tencentdb_superuser=C/postgres}
 nomal_1   | {=Tc/nomal_usr1,nomal_usr1=CTc/nomal_usr1}
 db_priv   | {=Tc/dbadmin,dbadmin=Tc/dbadmin}
(5 rows)
As shown in the figure above, the nspacl field clearly describes the account's permissions on the schema. We find the corresponding account's permissions, revoke them, and then delete the account.
(2) To check whether the account has permissions on certain schemas, you can query under each database. Refer to the following command:
nomal_1=> select nspname,nspacl from pg_namespace;
      nspname       |                          nspacl                          
--------------------+----------------------------------------------------------
 pg_toast           | 
 pg_temp_1          | 
 pg_toast_temp_1    | 
 pg_catalog         | {postgres=UC/postgres,=U/postgres}
 public             | {postgres=UC/postgres,=UC/postgres}
 information_schema | {postgres=UC/postgres,=U/postgres,nomal_usr1=C/postgres}
 sche_priv          | {dbadmin=UC/dbadmin}
(7 rows)
As shown in the figure above, the nspacl field clearly describes the account's permissions on the schema. We find the corresponding account's permissions, revoke them, and then delete the account.
(3) To check whether the account has permissions on certain objects, you can query under each database. Refer to the following command:
nomal_1=> select relname,a.typname as reltype ,relacl from pg_class  join pg_type a on pg_class.reltype=a.oid ;
Examples of checking whether an account is the OWNER of a certain object are as follows:
(1) To check whether an account is the OWNER of a certain database, refer to the following example:
nomal_1=> SELECT r.rolname,d.datdba,datname AS database_name FROM pg_database d  left JOIN pg_catalog.pg_roles r  on d.datdba=r.oid WHERE d.datdba in (SELECT usesysid FROM pg_user WHERE usename in('dbadmin','nomal_usr1','nomal_usr2'));
  rolname   | datdba | database_name 
------------+--------+---------------
 dbadmin    |  16398 | db_priv
 nomal_usr1 |  16401 | nomal_1
(2) To check whether an account is the OWNER of a certain schema, refer to the following example:
nomal_1=>  SELECT n.nspname as schema_name, pg_catalog.pg_get_userbyid(n.nspowner) as schema_owner FROM pg_catalog.pg_namespace n ORDER BY schema_name;
    schema_name     | schema_owner 
--------------------+--------------
 information_schema | postgres
 pg_catalog         | postgres
 pg_temp_1          | postgres
 pg_toast           | postgres
 pg_toast_temp_1    | postgres
 public             | postgres
 sche_priv          | dbadmin
(3) To check whether the account is the OWNER of a certain object, refer to the following example:
nomal_1=> select * from (select relname,relnamespace as schema_name ,a.typname as reltype,pg_catalog.pg_get_userbyid(relowner )as owner from pg_class join  pg_type a on pg_class.reltype=a.oid ) d where owner in('dbadmin','nomal_1');
    relname     | schema_name |    reltype     |  owner  
----------------+-------------+----------------+---------
 pg_toast_16488 |          99 | pg_toast_16488 | dbadmin
 amyttt         |       16480 | amyttt         | dbadmin
 am             |        2200 | am             | dbadmin
 am_s           |       16480 | am_s           | dbadmin
 bug_id_seq     |        2200 | bug_id_seq     | dbadmin
 bug            |        2200 | bug            | dbadmin
 pg_toast_16507 |          99 | pg_toast_16507 | dbadmin
Locking an Account
You can lock an existing account by clicking Operation > Lock account, as shown below:
﻿
The pop-up box is shown below:
﻿
After an account is locked, its status will become locked, as shown below:
Note：
When an account is subjected to a lock operation, the management system modifies the system permissions to NOLOGIN and sets CONNECTION to 0.
When an account is locked, all currently active connections are immediately terminated.
﻿
﻿
﻿
After an account is locked, you can unlock it on the console by clicking Operation > More > Unlock Account, as shown below:
﻿
﻿
﻿
Note:
When an account is unlocked, the management system will change the account's system permission to LOGIN and set CONNECTION to -1.
Exporting a List
The console supports two types of account list export: downloading current page data and downloading all data, as shown below:
﻿
﻿
﻿

PUBLIC Permission Operation

Last updated：2025-11-03 14:21:06

When creating specific objects in PostgreSQL, the system will grant default permissions to the PUBLIC role. The default permissions granted to PUBLIC are as follows. For more permission descriptions, refer to PostgreSQL official documentation:
Object Type
Default PUBLIC Permission
Databases
CONNECT,TEMPORARY
Functions/Procedures
EXECUTE
Languages
USAGE
Data Types
USAGE
Granting permissions to PUBLIC is equivalent to granting them to all users, including those not explicitly created. You can revoke these default PUBLIC permissions as needed for more precise database user authorization. The following context provides detailed examples.
Note:
Kernel versions supporting PUBLIC role-based permission operations are v13.22_r1.26, v14.19_r1.35, v15.14_r1.20, v16.10_r1.15, v17.6_r1.9 and above. TencentDB for PostgreSQL instances with historic kernel minor versions must upgrade minor kernel version to use this capacity.
TencentDB for PostgreSQL instances with historic kernel minor versions must execute drop extension tencentdb_superuser; in the corresponding database, then execute create extension tencentdb_superuser; before using this capacity after upgrading the kernel minor version.
Assuming you have two database accounts, am_a and dbadmin, as shown below. For user creation, refer to Console Operation Guide:
﻿
Among them, the database account dbadmin is the OWNER of database test_db, as shown below:
﻿
First, we use the account dbadmin to log in to the database test_db, as shown below:
[am@VM-91-60-centos ~]$psql -h10.*.*.* -p5432 -Udbadmin -dtest_db
Password for user dbadmin: 
psql (16.0, server 16.10)
Type "help" for help.
Switch to the am_a account. We can verify that am_a has login permission for the database and query permission for system tables via PUBLIC, as follows:
test_db=> \c - am_a
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "am_a".
test_db=> select oid FROM pg_class LIMIT 1;
 oid  
------
 2619
(1 row)
After reclaiming PUBLIC permission with the dbadmin account, the am_a account cannot access system tables:
test_db=> \c - dbadmin
Password for user dbadmin: 
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "dbadmin".
test_db=> REVOKE SELECT ON pg_class FROM PUBLIC;
REVOKE
test_db=> \c - am_a
Password for user am_a: 
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "am_a".
test_db=> select oid FROM pg_class LIMIT 1;
ERROR:  permission denied for table pg_class
After reclaiming PUBLIC permission with the dbadmin account, the am_a account is unable to connect to database test_db.
test_db=> \c - dbadmin
Password for user dbadmin: 
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "dbadmin".
test_db=> REVOKE CONNECT ON DATABASE test_db FROM PUBLIC;
REVOKE
test_db=> \c - am_a 
Password for user am_a: 
connection to server at "10.*.*.*", port 5432 failed: FATAL:  permission denied for database "test_db"
DETAIL:  User does not have CONNECT privilege.
Previous connection kept
After regranting am_a privileges using the dbadmin account, am_a can connect to the database test_db and can access system tables:
test_db=> \c - dbadmin
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "dbadmin".
test_db=> GRANT CONNECT ON DATABASE test_db TO am_a;
GRANT
test_db=> GRANT SELECT ON pg_class TO am_a;
GRANT
test_db=> \c - am_a
Password for user am_a: 
psql (16.0, server 16.10)
You are now connected to database "test_db" as user "am_a".
test_db=> select oid FROM pg_class LIMIT 1;
 oid  
------
 2619
(1 row)

Database Management

Database Management via Console

Last updated：2025-07-22 20:25:30

TencentDB for PostgreSQL supports managing databases in the console, as described below.
Creating a Database
Log in to the Cloud Database PostgreSQL Console, click Instance ID or the Operation column's Manage to enter the instance details page. Click Database Management > Database List> Create Database to create a database. The details are as follows:
Note:
The database name cannot be a system-reserved keyword. For specific keywords, refer to the official documentation.
﻿
﻿
Database List
Click Instance ID or the Operation column's Manage to enter the instance details page. Click Database Management to view the database list. The details are as follows:
﻿
Changing OWNER
Click Instance ID or the Operation column's Manage to enter the instance details page. Click Database Management to view the database list. In the Operation column, click Change Owner to modify the database owner. The details are as follows:
﻿
Delete Database
The current console does not support direct deletion of databases. If necessary, please click Delete in the Operation column. The system will automatically redirect you to the DMC management interface. Navigate to Database Management, then click Delete in the Operation column to complete the deletion process.
Note:
Deleting a database is a dangerous operation and may lead to data loss. Proceed with caution.
﻿
Description of Collation and Character Classification
In PostgreSQL, collation (mainly controlled by LC_COLLATE) and character classification (mainly controlled by LC_CTYPE) determine the sorting and comparison methods of string data as well as the classification attributes of characters. For detailed information on collation and character classification, refer to PostgreSQL’s official documentation on collation and locale.
Note:
Make sure consistent use of collation and character classification throughout the database to avoid inconsistencies in character processing behavior.

Parameter Management

Setting Instance Parameters

Last updated：2025-08-14 16:29:50

You can view and modify certain parameters and query parameter modification logs in TencentDB for PostgreSQL console.
Notes
To ensure instance stability, only some parameters can be modified in the console. These parameters are displayed on the Parameter Settings page.
If the modified parameter requires instance restart to take effect, the system will ask you if you wish to restart. We recommend that you do so during off-peak hours and ensure that your application has a reconnection mechanism.
Note: 
Some are key parameters, modifying which may affect your use or the normal running of the instance. Therefore, exercise caution when modifying key parameters.
Modifying Parameters in the Parameter List
Modifying parameters in batches
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an Instance ID or Manage in the Operation column to access the instance management page.
2. On the Parameter Settings tab, click Batch Modify Parameters.
﻿
3. Locate the desired parameters, and modify their values in the Current Value column. After confirming that everything is correct, click Confirm Modification.
﻿
4. In the pop-up dialog box, confirm that all parameter values are correctly modified, and click OK.
Note: 
If there are modified parameters requiring instance restart to take effect, click Restart Now and then the instance will be restarted. The modified parameters take effect only after the restart is completed.
﻿
Modifying one parameter
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an Instance ID or Manage in the Operation column to access the instance management page.
2. On the Parameter Settings tab, locate the desired parameter in the parameter list and click 
﻿
 in the Current Value column.
﻿
3. Modify the value within the restrictions stated in the Acceptable Values column and click 
﻿
 to save the modification. You can click 
﻿
 to cancel the operation.
4. In the pop-up dialog box, confirm that the parameter value is correctly modified, and click OK.
Note: 
If the modified parameter requires instance restart to take effect, click Restart Now and then the instance will be restarted. The modified parameter takes effect only after the restart is completed.
Viewing Parameter Modification Logs
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an Instance ID or Manage in the Operation column to access the instance management page.
2. On the Parameter Settings tab, click Recent Modifications on the right.
3. You can view the recent parameter modification records here.
﻿

Parameter Value Limits

Last updated：2025-06-16 17:32:07

This document describes instance parameters that cannot be modified due to instance specification limits and their required values.
Notes
Setting the following parameters will use system resources. To prevent the database use from being affected by parameter values, configure them as needed.
Note: 
Some are key parameters, and changing them may affect your use or the normal running of the instance. Therefore, exercise caution when modifying key parameters.
Limits on Parameter Values Restricted by Specification
Specification\Parameter
max_replication_slots
max_wal_senders
max_worker_processes
max_logical_replication_workers
max_parallel_workers
max_connections
1C2GiB
[10-100]
[27-150]
[4-300]
[4-150]
[8-8]
[100-2048]
2C4GiB
[10-100]
[27-150]
[4-300]
[4-150]
[8-8]
[100-2048]
2C6GiB
[10-150]
[27-200]
[4-400]
[4-200]
[8-8]
[100-2048]
4C8GiB
[10-150]
[27-200]
[4-400]
[4-200]
[8-8]
[100-2048]
4C16GiB
[10-150]
[27-200]
[4-400]
[4-200]
[8-8]
[100-2048]
6C24GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-12]
[100-2048]
8C16GiB
[10-150]
[27-200]
[4-400]
[4-200]
[8-8]
[100-2048]
8C32GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-16]
[100-4000]
8C48GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-16]
[100-4500]
8C64GiB
[10-400]
[27-450]
[4-900]
[4-450]
[8-24]
[100-5500]
12C24GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-12]
[100-2048]
12C64GiB
[10-400]
[27-450]
[4-900]
[4-450]
[8-24]
[100-5500]
16C32GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-16]
[100-4000]
16C96GiB
[10-400]
[27-450]
[4-900]
[4-450]
[8-32]
[100-8000]
20C128GiB
[10-500]
[27-450]
[4-900]
[4-450]
[8-40]
[100-10000]
24C48GiB
[10-200]
[27-250]
[4-500]
[4-250]
[8-16]
[100-4500]
24C192GiB
[10-500]
[27-550]
[4-1200]
[4-550]
[8-50]
[100-12000]
28C240GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-13000]
32C64GiB
[10-400]
[27-450]
[4-900]
[4-450]
[8-24]
[100-5500]
48C480GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-22000]
64C256GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-13000]
64C384GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-20000]
64C512GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-22000]
90C720GiB
[10-600]
[27-650]
[4-1300]
[4-650]
[8-60]
[100-36000]

Parameter Template

Last updated：2025-06-09 10:25:33

Parameter Template refers to a predefined group of parameter settings. One template can be applied to multiple database instances simultaneously.
By creating a custom parameter template in the TencentDB for PostgreSQL console and applying it to instances, you can conveniently and efficiently implement batch parameter settings for similar instances.
You can log in to the PostgreSQL console and select the Parameter Templates page in the left sidebar to manage it. The parameter template supports the following features:
create template, generate a custom parameter optimization scheme.
Use the PostgreSQL configuration file **.conf to import and create a template.
Save existing parameter settings as a template.
When setting parameters for one or multiple instances, directly import an existing template.
Compare the content between two parameter templates.
Note:
Database instances that have used parameter template will not be synchronously updated as the parameter template are modified. You need to manually apply the updated parameter template to the instances.
If you need to apply the newly created parameter template to batch instances, click Apply Template in parameter settings on the instance details page to import.
Create New Parameter Template
When you want to use your own database parameter templates, just create a new one, modify the desired parameters and apply it to your database instance, and then you can use the new database parameter templates.
1. Log in to the PostgreSQL console, select the Parameter Templates page in the left sidebar, and click Create Template.
2. In the pop-up dialog box, configure the following parameters and click Create and Set Parameters.
Template Name: Enter the name of the input parameter template. The name must be unique. It only supports numbers, English uppercase and lowercase letters, Chinese characters, and some special characters such as _ - / () + = : @. The length should not exceed 60 characters.
Engine: Select the corresponding database engine based on the database type required by the template, such as PostgreSQL or SQL Server-compatible. Different database engines support different parameters.
Database Version: Parameter templates can only be applied to database instances with the same database version. If you want to apply it to database instances of multiple versions, it is advisable to create a separate parameter template for each version individually to ensure that the parameter items match the version.
Template Description: Briefly explain the input parameter template. 
﻿
3. After the instance is created, you can click to view details and perform operations such as modifying, importing, and exporting parameters on the template details page.
Apply Parameter Template to Instance
Note:
When applying the parameter templates to multiple instances, please confirm the database engine and version of the parameters to ensure that they are applicable to the target instances. Proceed with caution to prevent database performance anomalies.
1. Log in to the PostgreSQL console and select the Parameter Templates page in the left sidebar.
2. In the parameter template list, find the template to be applied and click Apply to Instance in the Operation column.
﻿
3. In the pop-up page, select the instances for parameter application, check that the parameter modifications are correct, and then click Submit.
PostgreSQL instance: After selecting the corresponding region, the system will display the instances in that region whose database version matches that of the parameter template. You can select the instances to which the parameter template needs to be applied.
Parameter comparison: The parameter values of the selected instance before and after applying the template are viewable.
﻿
Copy Parameter Template
If you've created a database parameter template and want to include most of its custom parameters and values in a new one, copying the parameter template is a convenient solution.
Method One: Copy a Parameter Template From an Existing One
1. Log in to the PostgreSQL console, select the Parameter Templates page in the left sidebar, click the Template ID or Operation column's View Detail, and enter the template details page.
2. On the template details page, click Save as Template.
﻿
3. In the pop-up dialog box, configure the following parameters:
Template name: Enter the name of the input parameter template. The name must be unique.
Template description: Briefly explain the input parameter template.
The new copied template will have the same engine and database version as the original template.
﻿
4. Confirm that everything is correct. Click OK to save the current parameter template as a new one and complete the copy operation.
Method Two: Copy a Parameter Template through the Feature Setting of an Instance
1. Log in to the PostgreSQL console, select the Instance List page in the left sidebar, and click the Instance ID to enter the management page.
2. Select the Parameter Settings page and click Save as Template.
3. In the pop-up dialog box, configure the following parameters:
Template name: Enter the name of the input parameter template. The name must be unique.
Template description: Briefly explain the input parameter template.
The newly copied template will have the same engine and database version as the current instance information.
4. Confirm that everything is correct. Click OK to save the current parameter template as a new one and complete the copy operation.
Modify the Parameter Value of a Parameter Template
1. Log in to the PostgreSQL console, select the Parameter Templates page in the left sidebar, click the Template ID, and enter the template details page.
2. On the template details page, click Batch Modify Parameters or click the "Modify Parameter Value" icon in the parameter runtime value column.
﻿
Import Parameter Template
1. Log in to the PostgreSQL console, select the Parameter Templates page in the left sidebar, click the Template ID, and enter the template details page.
2. On the template details page, click Export Parameters.
﻿
Note:
Select import parameters, which means choosing a configuration file (.conf format) from the local file for import. Need to pay attention that the format of the configuration file should be consistent with that of the PostgreSQL database server's configuration file, or use the file template of the exported parameters. Otherwise, it will prompt that the import is unsuccessful.
3. In the pop-up dialog box, select a file and click Import and Overwrite Original Parameters.
Export Parameter Template
Method 1: Export From the Parameter Template List
1. Log in to the PostgreSQL console and select the Parameter Templates page in the left sidebar.
2. In the parameter templates list, in the Operation column of the desired template, click Export.
Method 2: Export From the Parameter Template Details
1. Log in to the PostgreSQL console, select the Parameter Templates page in the left sidebar, click the Template ID, and enter the template details page.
2. On the template details page, click Export Parameters at the top.
Delete Parameter Template
If you've created extra parameter template or confirmed that a parameter template has no used value, you can use the deleting parameter template functionality to delete the parameters used no longer.
1. Log in to the PostgreSQL console and select the Parameter Templates page in the left sidebar.
2. In the parameter templates list, in the Operation column of the desired template, click Delete.
﻿
3. In the pop-up dialog box, click OK.

Setting soft_limit_connections Parameters

Last updated：2024-10-28 15:03:30

Due to the needs of primary-secondary replication, the max_connections parameter value of the secondary database in PostgreSQL, must be greater than or equal to that of the primary database in it. Therefore, the max_connections parameter value of the primary instance may not be set to the maximum value allowed by its specification due to the configuration of the read-only instance and the primary instance. At this point, you can resolve this issue by enabling the soft_limit_connections parameter. Below, we will describe this in detail.
Note:
When the soft_limit_connections parameter is set to a value other than -1, the number of connections to the instance will be controlled by this parameter. If your TencentDB for PostgreSQL instance does not have any restrictions, it is recommended not to modify this parameter.
Suppose you now have a primary instance and two read-only instances. The configurations are as follows:
Instance Type
Instance Configuration
Maximum max_connections Value
Primary instance
8 CPU cores and 48 GB memory with 100 GB disk
4500
Read-only instance
1 CPU core and 2 GB memory with 100 GB disk
2048
Read-only instance
1 CPU core and 2 GB memory with 100 GB disk
2048
If you need to adjust the connection count of the primary instance to 4000, you can perform the following operation:
1. Modify the soft_limit_connections of all read-only instances
You can modify the soft_limit_connections parameter of the read-only instance to a value other than -1, then the connection count of the read-only instance will be controlled by the soft_limit_connections parameter. Modifying this parameter does not require a restart. You can search for soft_limit_connections in the Parameter Settings to change it, as shown below:
﻿
2. Modify the max_connections of all read-only instances
After modifying the soft_limit_connections parameter of the read-only instance to a value other than -1, the maximum limit of the max_connections parameter of the read-only instance will be consistent with that of the primary instance. Since the max_connections parameter value of the secondary database must be greater than or equal to that of the primary database, if you need to adjust the max_connections of the primary instance, you can first adjust the max_connections of the read-only instance to prepare for adjusting the max_connections of the primary instance later. You can search for max_connections in the Parameter Settings to change it, as shown below:
﻿
3. Modify the max_connections of the primary instance
If the max_connections of all read-only instances has been adjusted and you now want to adjust the connection limit of the primary instance to a higher value, you can directly modify the max_connections parameter of the primary instance. You can search for max_connections in the Parameter Settings to change it, as shown below:
﻿
At this point, the maximum connection count of your primary instance has been adjusted and is no longer limited by the specifications of the read-only instances.
If you no longer need to use the soft_limit_connections parameter to control the connection count of the read-only instances, you can follow the steps below to disable the parameter.
Modify the max_connections parameter of the primary instance to 2048
Modify the max_connections parameter of all read-only instances to 2048
Set the soft_limit_connections parameter of all read-only instances to -1

TencentDB for PostgreSQL UNLOGGED Table Usage Notes

Last updated：2026-01-26 14:15:59

UNLOGGED Table Description
Features of UNLOGGED Tables
1. An UNLOGGED table
An UNLOGGED table is a special type of table provided by PostgreSQL. Its characteristic is that it does not record WAL (Write-Ahead Log) logs in exchange for higher write performance.
2. UNLOGGED table characteristics
Performance characteristics
Write performance improvement: Skips WAL logging
Reduction in I/O overhead: No need to wait for log flushing to disk
Reduction in storage pressure: Decreases WAL log space consumption.
Data characteristics
Data are still written to disk: Normal data file storage.
No durability guarantee: Data loss occurs following a database restart.
Not supported for replication: Not synchronized to replicas.
3. Identify UNLOGGED tables
-- View table type
SELECT 
    schemaname,
    tablename,
    CASE 
        WHEN relpersistence = 'u' THEN 'UNLOGGED'
        WHEN relpersistence = 'p' THEN 'PERMANENT' 
        ELSE 'OTHER'
    END as table_type
FROM pg_tables t
JOIN pg_class c ON c.relname = t.tablename
WHERE schemaname = 'public';
UNLOGGED Table Risks
1. Data security risks
Data loss risk
Server restart: All UNLOGGED table data is cleared.
Database crash: Abnormal shutdown causes data loss.
Hardware failure: Cannot be recovered through WAL logs.
2. High availability limitation
Master-slave replication issues
Replica contains no data: UNLOGGED tables are not replicated to replicas.
Failure switchover risk: Data loss after master-slave switchover.
3. Backup and recovery limitations
Backup policy limitations
Logical backup: pg_dump does not include UNLOGGED table data by default.
Physical backup: Base backup does not include UNLOGGED table data.
Point-in-time recovery: Cannot recover historical data of UNLOGGED tables.
4. Feature compatibility limitations
Unsupported features
Logical replication: Cannot be used as a publication table.
Pub/Sub: Logical decoding is not supported.
Certain extensions: Some extensions may be incompatible.
UNLOGGED Table Use Cases
1. Suitable usage scenarios
ETL data processing
Cache and session storage
Ad hoc computing and statistics
2. Performance optimization scenarios
Batch data import
Temporary index building
3. Unsuitable usage scenarios
Business-critical data
Configuration data requiring persistence
Convert UNLOGGED tables to LOGGED tables
1. Syntax transformation
The basic conversion commands are as follows:
-- Convert UNLOGGED tables to regular tables, where unlogged_table_name is the table name
ALTER TABLE unlogged_table_name SET LOGGED;
﻿
-- Lock status monitoring: the mode field indicates the lock type, AccessExclusiveLock is the most restrictive lock, and unlogged_table_name is the table name
SELECT 
    l.locktype,
    l.mode,
    l.granted,
    l.pid,
    a.state,
    a.query_start,
    now() - a.query_start as duration,
    CASE 
        WHEN l.granted THEN 'GRANTED'
        ELSE 'WAITING'
    END as lock_status,
    substring(a.query, 1, 80) as query_snippet
FROM pg_locks l
LEFT JOIN pg_stat_activity a ON l.pid = a.pid
WHERE l.relation IS NOT NULL 
    AND EXISTS (
        SELECT 1 FROM pg_class c 
        WHERE c.oid = l.relation 
        AND c.relname = 'unlogged_table_name'
    )
ORDER BY l.granted, a.query_start;
2. Conversion considerations
Conversion process: requires rewriting the entire table.
Locking time: Conversion of large tables can be lengthy, during which the tables remain locked throughout the process.
Space requirements: Additional storage space is needed during the conversion process.
3. Conversion best practices
It is recommended to adopt a batch conversion policy, as shown in the following example:
-- For large tables, it is recommended to convert them in batches
-- 1. Create a new LOGGED table
CREATE TABLE user_cache_new (LIKE user_cache);
﻿
-- 2. Migrate data in batches
INSERT INTO user_cache_new 
SELECT * FROM user_cache 
WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02';
﻿
-- 3. Rename the table
BEGIN;
DROP TABLE user_cache;
ALTER TABLE user_cache_new RENAME TO user_cache;
COMMIT;
TencentDB for PostgreSQL Parameters
TencentDB for PostgreSQL introduces the tencentdb_log_unlogged_table parameter, while maintaining PostgreSQL's native functionality, to provide users with enhanced data security. For modifying parameters, see Setting Instance Parameters.
Note:
It is recommended to keep tencentdb_log_unlogged_table = on in production environments.
It is recommended to regularly check and monitor existing UNLOGGED tables and convert them promptly.
The versions supported by this feature are v11.22_r1.26, v12.22_r1.29, v13.20_r1.24, v14.17_r1.33, v15.12_r1.18, v16.8_r1.13, v17.4_r1.7, v18.0_r1.0 and above. It is recommended that you upgrade the kernel minor version as soon as possible.
Parameter Specifications
When tencentdb_log_unlogged_table = on (default):
All newly created UNLOGGED tables are automatically converted to LOGGED tables.
A WARNING prompt is displayed when a user creates an UNLOGGED table.
Existing UNLOGGED tables remain unchanged (require manual conversion).
Provides enhanced data security
-- Create UNLOGGED table
amy=> CREATE UNLOGGED TABLE test_table (id INT, data TEXT);
-- System WARNING:
WARNING:  change unlogged table to logged table, If you want to use unlogged tables, please set tencentdb_log_unlogged_table to false.
CREATE TABLE
-- Verify table type, returns: 'p' (PERMANENT/LOGGED)
am=> SELECT relpersistence FROM pg_class WHERE relname = 'test_table';
 relpersistence 
----------------
 p
(1 row
When tencentdb_log_unlogged_table = off:
All behaviors are consistent with native PostgreSQL.
Allows creation of genuine UNLOGGED tables
Users are responsible for assuming the risk of data loss.
Frequently Asked Questions (FAQ)
Does Modifying the tencentdb_log_unlogged_table Parameter Require Rebooting the Instance?
No. This parameter is dynamic and changes take effect immediately.
After the Parameter Is Set to on, Will Existing UNLOGGED Tables Be Converted Automatically?
No. The parameter only affects newly created tables. Existing UNLOGGED tables require manual ALTER TABLE SET LOGGED conversion.

Log Management and Analysis

Slow Query Analysis

Last updated：2026-02-11 20:33:56

Feature Description
Note:
Note: TencentDB for PostgreSQL supports slow SQL details and abstracted SQL statistics, both of which support downloading. Just click to download on the corresponding webpage.
The default database considers SQL statement queries exceeding 1s as "slow queries", and the corresponding statements are called "slow query statements" (commonly known as "slow SQL"). The process where a database administrator (DBA) analyzes slow query statements and finds out the reasons for slow query occurrence is called "slow query analysis".
Log in to the TencentDB for PostgreSQL console, click the Instance ID or Operation column's Manage, enter instance details, then click Performance Optimization on the instance management page. In the Slow Query Analysis module, you can view the slow query analysis provided by the system. As shown in the figure below:
﻿
Monitoring View
The two charts in the console provide a monitoring view, offering an intuitive way to view slow SQL information.
Slow query and other monitoring combined view: Support through charting format to view slow query metrics as well as the ability to compare with other metrics. Supported metrics include: CPU usage, QPS, request count, read request count, number of write requests, other requests, buffer cache hit rate, and average execution latency.
Slow SQL duration distribution: View slow queries through different time periods to see the main time period distribution.
Slow SQL List
The slow SQL list displays the generated slow SQL statements in real time. The list is sorted in descending order by time, with newly generated slow SQL automatically displayed on the first line.
Supported fields for viewing slow SQL: execution time, slow SQL statement, total time (seconds), client IP address, database, account. The explanation of each field is as follows:
Execution Time
Slow SQL statements: Detailed slow log SQL statements recorded.
Total time (seconds): The occupied time of executing this slow log SQL statement.
Client IP: Which clients the statement was executed on.
Database: Which database the PromQL statement called.
Account: Which user the statement was run with.
Note:
- The slow SQL list saves slow SQL data from the most recent 7 days and a maximum log volume of 50GiB by default. When either condition is met, logs exceeding the requirement are automatically deleted.
- If a single slow SQL exceeds 1 MB, you will not be able to view it in the console. Please submit a ticket to contact Tencent Cloud for assistance.
﻿
Slow SQL Statistical Analysis
Slow SQL statistical analysis can aggregate and analyze the same type of SQL based on abstract parameters obtained from ALL slow SQL over a specified time period. It includes multiple field info.
Last execution time: The time when the abstract statement last occurred within the statistical scope. Since specific statements may take extended time to execute, we unify the records by the begin_time of statement execution.
Abstracted SQL statement: The statement after removing constants from slow SQL. Abstracted statements can summarize similar statements of the same nature for better analysis.
Database: Which database the statement called.
Account: Which user the statement was run with.
Client IP address: Which clients the statement was executed on.
First execution time: The first occurrence of the slow SQL within the statistical scope (after abstraction, there may be multiple records).
Total execution time (seconds): The total time consumed by slow query statements within the statistical scope.
Average execution time (seconds): The average time of total time of slow query statements divided by total counts.
Minimum execution time (seconds): The minimum time among all slow query statements in this abstract statement; used to help judge whether this statement is sporadic.
Maximum execution time (seconds): The maximum time among all slow query statements in this abstract statement; used to help judge whether this statement is sporadic.
Total time percentage: The percentage of time consumed by slow query statements within the statistical scope.
Based on your needs, you can customize the list field to show SQL statistics, as shown below:
﻿
﻿

Error logs

Last updated：2025-07-22 20:25:30

Feature Description
Logs generated during database operation due to actions, SQL, or system runtime errors are called error logs. Error logs are often used by developers to find the causes for issues with the business system or database.
Log in to TencentDB for PostgreSQL, click Instance ID or Actions column Management, enter instance details, then click Performance Optimization on the instance management page, and click Error Log to view error log recording detected by the system. As shown in the figure below:
﻿
Error Log Default Configurations
Error log feature: enabled by default
Error log level: log_min_error_statement=ERROR
Analysis data output latency: 1 minute - 5 minutes
Log recording duration: 7 days (maximum 10,000 most recent)

Execution Log Management

Last updated：2025-11-03 14:26:13

This document introduces how to manage the retention duration of pg_log.
Introduction to PG_LOG
pg_log typically records the status information of the database, such as error information, slow log SQL, database startup and shutdown information, etc. This log will be automatically segmented by size and time, and the pg_log of TencentDB for PostgreSQL is retained by default for 30 days. pg_log will occupy the storage space of the database instance, and you can modify the retention duration based on your needs.
Note:
The slow log and error log of the database instance are retained for 7 days by default. Modifying the pg_log retention duration does not affect the slow log and error log retention duration.
Modifying PG_LOG Retention Duration
You can modify the pg_log retention duration based on your needs. The system currently supports two options: 7 days and 30 days. The detailed steps are as follows:
1. Sign in TencentDB for PostgreSQL Console.
2. Find the instance you need to modify in the instance list, click Operation > Manage to enter the instance details.
3. Find Parameter Settings in the Instance detail page, search for the parameter log_filename in the upper right corner and update it.
﻿
The introduction for the log_filename parameter is as follows:
Parameter Value
Description
postgresql_%a_%H.log
Selecting this value will keep logs for 7 days.
postgresql_%d_%H.log
Selecting this value allows logs to be retained for 30 days, which is the system default.
After modifying the log_filename parameter, you can set the number of retained running logs by modifying the tencentdb_max_logfile_num parameter to clean up historic log files. The system generates one log file per hour by default. Therefore, if the log_filename parameter is set to postgresql_%a_%H.log (7 days), set tencentdb_max_logfile_num to 168 or higher. If the log_filename parameter is set to postgresql_%d_%H.log (30 days), set tencentdb_max_logfile_num to 720 or higher. You can find the parameter setting on the instance details page by searching for tencentdb_max_logfile_num in the search box at the top right and updating it.
﻿
Note:
To retain sufficient running logs, set the tencentdb_max_logfile_num parameter to no less than 100.
The tencentdb_max_logfile_num parameter value 2147483647 means retain all.
If you cannot change the parameter tencentdb_max_logfile_num on the console, upgrade the minor kernel version.
Cleaning Extra Logs
For extra logs, you may execute the following statement after logging in to the instance to clean them immediately, or wait for the kernel to perform log rotation for auto cleanup.
SELECT pg_rotate_logfile();

Log Shipping

Last updated：2025-10-15 20:18:39

TencentDB for PostgreSQL provides a log shipping feature. Through log shipping, you can collect slow log and error log data from TencentDB for PostgreSQL instances and ship it to Cloud Log Service (CLS) for analysis, enabling quick monitoring and troubleshooting of business issues. This document describes how to enable or disable the log shipping feature via the console.
Prerequisites
Before using this feature, please ensure:
The CLS has been successfully activated.  
A service role for PostgreSQL has been created and the necessary permissions have been granted.  
Definition of Error Logs
Field value.
Type
Description
Timestamp
-
A reserved field for CLS, which represents the log generation time.
InstanceId
String
Database instance ID, such as postgres-xxx.
Database
Long
The database used by the client to connect to the database instance.
UserName
String
The username used by the client to connect to the database instance.
ErrMsg
String
Original SQL error logs.
ErrTime
String
Error occurrence time.
Definition of Slow Logs
Field value.
Type
Description
Timestamp
-
A reserved field for CLS, which represents the log generation time.
InstanceId
String
Database instance ID, such as postgres-xxx.
DatabaseName
String
The database to which the client connects.
UserName
String
User of client connection.
RawQuery
String
Slow log content.
Duration
String
Duration.
ClientAddr
String
Client address.
SessionStartTime
Unix timestamp
Session start time.
Enabling Slow Log Shipping
1. Log in to the TencentDB for PostgreSQL console and click Instance ID in the instance list to go to the management page.
2. On the instance management page, select Performance Optimization > Log Shipping.
3. In the Slow Query Log Shipping section, click the Enable Now button.  
﻿
4. Complete the following configuration in the pop-up window, and click Enable Now.
﻿
Parameter
Description
Destination region
Select the region for log shipping, supporting offsite shipping.
Log topic operations
Log topics serve as the fundamental units for collecting, storing, retrieving, and analyzing log data. You can either select an existing log topic or create a new one.
Logset
Logsets serve as a classification mechanism for log topics, enabling efficient management of log topics. You can either select existing log topics or create new ones as needed.
Select an existing logset: You can filter existing logsets in the search box to categorize slow log shipping.
Create a logset: You can create a new logset to categorize slow log shipping. Only English letters, digits, and underscores are supported, and the length cannot exceed 20.
Log Topic
Select an existing log topic: This option is available only when an existing logset is selected. You can filter log topics under the selected logset in the search box.
Create a log topic: Create a new log topic under the selected logset. Only English letters, digits, and underscores are supported, and the length cannot exceed 20.
Note:
You can manage log topics. For details, see Managing Log Topics.
Note:
Enabling log delivery will automatically activate log indexing by default. It is enabled by default. Index configuration is a necessary condition to use CLS for retrieval and analysis. Only by enabling the indexing feature can you retrieve and analyze logs. For details, see Index Configuration.
If an existing log topic is selected, the index status will be consistent with the index status of the corresponding existing log topic by default.
5. After slow log shipping is successfully enabled, you can see that slow log shipping is enabled under Log Shipping. Click the log topic name to jump to the CLS console for subsequent analysis and management.
﻿
Disabling Slow Log Shipping
Note:
After slow log shipping is disabled, the generated slow log shipping data will be saved at the saving time selected when slow log shipping is enabled, and will be automatically cleared only after expiration.
1. Log in to the TencentDB for PostgreSQL console and click Instance ID in the instance list to go to the management page.
2. On the instance management page, select Performance Optimization > Log Shipping.
3. In Slow Query Log Shipping, click Disable Shipping.
4. In the pop-up window, select Disable and click Confirm.
﻿
Enabling Error Log Shipping
1. Log in to the TencentDB for PostgreSQL console and click Instance ID in the instance list to go to the management page.
2. On the instance management page, select Performance Optimization > Log Shipping.
3. In Error Log Shipping, click the Enable Now button.
4. Complete the following configuration in the pop-up window, and click Enable Now.
﻿
Parameter
Description
Destination region
Select the region for log shipping, supporting offsite shipping.
Logset Operation
A logset categorizes log topics to facilitate your management of log topics. You can select an existing logset or create a logset.
Logset
Select an existing logset: You can filter existing logsets in the search box to categorize error log shipping.
Create a logset: You can create a new logset to categorize error log shipping. The naming format for creating a logset is custom_logset, where the custom part supports only English letters, digits, and underscores, with a length not exceeding 20.
Log Topic
Select an existing log topic: This option is available only when an existing logset is selected. You can filter log topics under the selected logset in the search box.
Create a log topic: You can create a new log topic under the selected logset. The naming format for creating a log topic is custom_topic, where the custom part supports only English letters, digits, and underscores, with a length not exceeding 20.
Note:
You can manage log topics. For details, see Managing Log Topics.
Note:
It is enabled by default. Index configuration is a necessary condition to use CLS for retrieval and analysis. Only by enabling the indexing feature can you retrieve and analyze logs. For details, see Index Configuration.
If an existing log topic is selected, the index status will be consistent with the index status of the corresponding existing log topic by default.
5. After error log shipping is successfully enabled, you can see that error log shipping is enabled under Log Shipping. Click the log topic name to jump to the CLS console for subsequent analysis and management.
﻿
Disabling Error Log Shipping
Note:
After error log shipping is disabled, the generated error log shipping data will be saved at the saving time selected when error log shipping is enabled, and will be automatically cleared only after expiration.
1. Log in to the TencentDB for PostgreSQL console and click Instance ID in the instance list to go to the management page.
2. On the instance management page, select Performance Optimization > Log Shipping.
3. In Error Log Shipping, click Disable Shipping.
4. In the pop-up window, select Disable and click Confirm.
Documentation
﻿Logset﻿
﻿Managing Log Topics﻿
﻿Dashboard﻿
﻿Data Processing﻿
﻿Retrieval and Analysis﻿

Backup and Restoration

Backup Principles and Solutions

Last updated：2024-03-20 14:30:33

TencentDB for PostgreSQL supports Data Backup, Manual Backup, and Log Backup. You can schedule regular database backups through automatic backup settings. In the event of a database failure or accidental deletion, you can restore the database from the stored backup files. TencentDB for PostgreSQL supports storing database backups in a compressed format. The size of a compressed backup file is approximately 30% of its original size (the exact compression ratio depends on the amount of duplicated data stored in the instance, the more duplicate data, the greater the compression ratio).
Backup Principles
For the double-availability (primary-standby) architecture, when a backup task is triggered, the system pulls data from the instance's standby node and compresses it before uploading it to the object storage service. Backup space does not occupy the disk space of the instance. If a database failure or accidental deletion occurs, you can recover the database from the stored backup files. When restoring data, you can use the cloning method, please refer to Cloning Instances, or you can download the backup files for recovery, please refer to Restoring PostgreSQL Data on CVMs. The principle is shown in the following figure:
﻿
﻿
﻿
Backup Plans
Operation Type
Backup Type
Operation Details
Data Backup
Data Backup
The system will trigger a full data backup according to your automatic backup setting within the specified time. The backup method is physical backup, which offers fast backup speed and higher recovery efficiency.
The generated full automatic backup data is retained based on the data backup retention time you set. The backup data will not be deleted when the instance is terminated. It will be automatically deleted when it expires. This can meet your need to extend the retention of backup data to prevent serious impact due to accidental deletion of instances. Since full backup uses backup storage space, you can delete it promptly if necessary.
The automatic backup data within one week cannot be deleted, while data older than one week can be flexibly deleted according to your needs. Please be cautious when deleting backup data as it cannot be recovered after deletion.
﻿
Manual Backup
You can manually initiate a full instance backup based on application needs through the console. After the manual backup task is initiated, the system will perform a full instance backup using the physical backup method within 1 minute.
The expiration time of manual backups is one week after they are initiated. Since manual backups occupy backup storage space, you can delete manual backups promptly if necessary.
﻿
Incremental Backup
Incremental backup is WAL log backup, which is automatically enabled by default and cannot be disabled. The incremental backup is stored based on the data backup retention time you set. The system will perform real-time backup based on the WAL log generated by the database. Since incremental backup occupies backup storage space, you can delete it promptly if necessary.
Incremental backup data within a week is not allowed to be deleted, while data older than one week can be flexibly deleted according to your needs. After the incremental backup data is deleted, point-in-time recovery cannot be performed, so exercise caution when deleting incremental backup data.
Backup Files Download
Download Full Backup
Supports local browser download and download by address.
﻿
Download Incremental Backup
Supports local browser download and download by address.
Transfer Historical Backup Through Serverless Cloud Function
Transfer through Serverless Cloud Function
You can transfer historical backup data using the Serverless Cloud Function. For more information, please see Use Serverless Cloud Function to transfer historical PostgreSQL backup.
Backup Fees
TencentDB for PostgreSQL Backup files are stored in the form of compressed files, and the compressed backup file size is about 30% of the original file size. The single instance backup space is given according to the purchased capacity and most instances don't need to pay. For the specific billing rules, please refer to Backup Space Billing.
﻿

Backing up Data

Last updated：2025-08-14 16:35:08

This document describes how to set backup parameters and download backup files via the TencentDB for PostgreSQL console.
Operation Scenarios
Currently, TencentDB for PostgreSQL High Availability Edition only supports physical backup:
Full backup: once a day at 01:00.
Incremental backup: for xlog files, backup will be performed once every 15 minutes or when the number of files reaches 60.
Data file retention period:Range: 7 to 1830 days.
Manual Backup: If you initiate a backup task manually, the task will start within one minute after you click OK.
Directions
1. Log in to the TencentDB for PostgreSQL Console and click an Instance ID to enter the instance details page.
2. The system will initiate automatic backups by default. For detailed information, please refer to the Automatic Backup Settings.
3. Backup data is available for download. On the instance management page, navigate to the Backup and Restoration section, then select either the Data Backup List or the Log Backup List. Choose the backup you wish to download and click Download in the Operation column.
Note: 
Backup data in the Data Backup List is full backup, while that in the Log Backup List is incremental backup.
﻿
4. In the pop-up window, you can choose a VPC address or public network address to download the backup file.
Note: 
To ensure data security, an address will be valid for 12 hours. After it expires, please refresh the page to get a new address. Please access a VPC address in a VPC.  
﻿
5. In addition to automatic system backups, users can initiate manual backup tasks on demand. Simply click the Manual Backup button on the Backup and Restoration page to start a manual backup.
Note:
You can not initiate a manual backup during the execution of the routine auto backup tasks.
Manual backups can be deleted from the backup list to free up backup space, avoiding space waste and occupancy. If not manually deleted, they will be kept forever.
﻿
6. In the Manual Backup dialog, click OK.
﻿
Note:
The creation time of a manual backup relates to the actual capacity of the instance. Larger capacity results in longer creation time.
 FAQs 
Can backups exceeding the retention period still be downloaded or restored?
Expired automatic backup sets will be automatically deleted and cannot be downloaded or restored. You can manually backup instance data in the console, and manual backups are always saved.
Can backups be manually deleted?
Automatic backups within 7 days cannot be deleted. Those beyond 7 days can be deleted as needed, and the system will also delete automatic backups based on their corresponding retention durations. Manual backups can be manually deleted from the backup list; otherwise, they will be retained permanently.
Can data and log backups be disabled?
No, they cannot be disabled. However, you can lower the backup frequency and delete unnecessary to reduce the backup space usage.
How can I reduce backup space overhead?
Delete unnecessary manual backup data.
Lower the automatic backup frequency for non-core service data (at least twice a week).

Downloading Backup

Last updated：2025-08-14 16:38:17

This document describes how to download backup files in the TencentDB for PostgreSQL console.
Note
Both private address and local download address are valid for 12 hours. Refresh the page to get new ones upon expiration.
The URL must be enclosed with quotation marks when the wget command is used to download.
After the file is downloaded, you need to decompress it using zstd. If this tool is not available, install it.
Directions
Data backup download
1. Log in to the TencentDB for PostgreSQL console, select a region, and click an instance ID to access the instance management page.
2. On the instance management page, select the Backup and Restoration tab and click Data Backup List.
﻿
3. Select the backup you want to download from the backup list and click Download in its Operation column.
4. In the download window, both VPC address and local download address are provided for download.
Note:
We recommend that you copy the download address, log in to a Linux CVM instance in the same VPC as the TencentDB instance, and run the wget command for fast download over the private network. For more information, see Customizing Linux CVM Configurations.
﻿
5. You can also click Database Backup on the left sidebar to enter the Backup List page, and click Data Backup List to download the data backup.
Log backup download
1. Log in to the TencentDB for PostgreSQL console, select a region, and click an Instance ID to access the instance management page.
2. On the instance management page, select the Backup and Restoration and click Log Backup List.
﻿
3. Select the backup you want to download from the log backup list and click Download in its Operation column.
4. In the download window, both VPC address and local download address are provided for download.
﻿
5. You can also click Database Backup on the left sidebar to enter the Backup List page, and click Log Backup List to download the data backup.

Cloning Instance

Last updated：2024-01-24 11:16:51

This document describes how to clone a TencentDB for PostgreSQL instance in the console. This feature enables you to quickly restore original instance data from a backup to a newly purchased instance.
Overview
You can restore a TencentDB for PostgreSQL instance to any time point within the log backup retention period or from a specific physical backup set through instance clone. The clone is a new instance created from the backup data according to the restoration time point you specify. After the clone is verified, you can migrate its data back to the original instance with DTS or directly use the clone.
Clone mode
Clone an instance and restore the clone to any time point within the log backup retention period you specify.
Clone an instance and restore the clone from a specific physical backup set within the data backup retention period you specify.
Clone billing
You can select a billing mode for the clone during the clone process in the same way as during instance purchase.
The clone will not be billed until the clone process is completed.
Prerequisites
The original instance must be in the Running status.
If the clone mode is set to By backup set, the original instance must have created at least one physical backup. You can log in to the console, select Database Backup on the left sidebar, and view backup status on the Backup List tab.
Your account balance must be positive.
Notes
The hard disk space of the clone must be larger than the amount of the data to be cloned from; otherwise, the clone task may fail.
The database version of the clone must be the same as that of the original instance.
For instances with a used capacity greater than 6 TB, submit a ticket for data restoration.
Directions
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance management page, select Backup and Restoration > Backup List and click Clone in the top-left corner, or locate the target backup and click Clone in the Operation column.
﻿
﻿
3. On the displayed purchase page, specify the clone mode and other configurations and click Buy Now.
By time point: You can restore an instance to any time point within the past seven days.
By backup set: You can restore data from a backup set to a new instance. The available backup sets depend on the data backup retention period.
Note: 
You can log in to the console, select Database Backup on the left sidebar, and view backup retention period on the Backup List tab.
﻿
4. After successful purchase, you can view the details of the clone on the instance list page.
FAQs
Will the access to the original instance be affected during the clone process?
The original backup set and log files uploaded to COS are used for restoration, which will not affect the access to the original instance.

Automatic Backup Settings

Last updated：2025-05-19 12:01:32

TencentDB for PostgreSQL automatically backs up data according to the default backup settings. You can also modify the automatic backup settings and select to perform backups during resource idle time all day. This document introduces how to perform automatic backup settings through the PostgreSQL console.
Notes
It is recommended that you try to choose off-peak periods to perform backups.
Backup may take a long time if the data volume is large.
Backup files have a retention time, which defaults to 7 days. Please download promptly the backup files that need to be kept to your local system, or use SCF to transfer PostgreSQL historical backups.
The backup mode is physical backup, while logical backup is not supported currently.
Directions
1. Log in to the TencentDB for PostgreSQL console. In the instance list, select a region and click an instance ID to enter the instance management page.
2. On the instance management page, select the Backup and Restoration tab and click Auto-Backup Settings.
﻿
3. In the pop-up backup settings window, perform the configuration of the following options.
﻿
Parameter
Description
Backup Start Time
Support selecting the default time (to perform backup during idle time of resources throughout the day) or customizing the backup start time. The backup will be initiated within this time range. If the backup fails to be initiated within this time period due to an unexpected reason, this backup will no longer start and will be initiated during the next backup start time period.
Default time is the backup initiation time automatically assigned by the system.
Support custom selection of backup start time. Set it to the off-peak period. Backup initiation time is merely the time when the backup starts and does not represent the backup end time.
For example, if you select 02:00 - 06:00 to enable backup, the system will initiate backup at a certain point within the time range of 02:00 - 06:00, depending on the backend backup policy and backup system status.
Weekly Backup
Select by the scale of one week, and support consecutive or interval selection from Monday to Sunday.
Chosen by default for Monday to Sunday, 7 days. Support custom selection of backup time. However, to ensure the security of your data, please set up at least two backups per week.
Weekly backup retention time
Weekly backup files can be retained for 7–1830 days. It defaults to 7 days. The backup set will be auto-deleted upon expiry.
Monthly Backup
Select based on a one-month (31 days) scale. The backup data backed up monthly can be set with a separate retention time.
Off by default. After turning on the switch, you can choose any number of days from 1 to 31.
Particularly, if the 31st is selected, the backup this time will be skipped directly in months without the 31st.
Monthly backup and weekly backup are carried out simultaneously, and all data will be stored.
Monthly backup retention time
Monthly backup files can be retained for 7–1830 days. It defaults to 7 days. The backup set will be auto-deleted upon expiry.
log backup retention time
Log backup data retention time setting: Retainable for 7–1830 days, defaults to 7 days.
4. Once configured, click OK. Once the notification in the upper-right corner prompts that the backup setting is successful, the automatic backup setting is completed.
﻿

Restoring PostgreSQL Data on CVMs

Last updated：2025-09-10 22:12:08

When data is lost or corrupted, you can use the console's instance cloning feature to restore data to a specific time point or from a backup set. The restorable time is determined by the log retention period and the full-backup time. You can also directly download the backup and restore it to a self-built database. A detailed description is provided below.
Note:
If transparent data encryption (TDE) is enabled for the TencentDB for PostgreSQL instance, recovery to a self-built database is not supported.
Downloading a Backup in the Console for Restoration
1.Prerequisite
The PostgreSQL database with the same version as the backup data must be installed in the Cloud Virtual Machine (CVM) where data is to be restored. For detailed installation instructions, refer to the official documentation for PostgreSQL. For Linux CVM configuration, see Quickly Configuring Linux CVM.
2.Creating a Recovery Directory with the Postgres User
To recover data, you first need to create a recovery directory on the CVM and set permissions.
mkdir -p /var/lib/pgsql/16/recovery
chown postgres /var/lib/pgsql/16/recovery
Here, 16 is an example of a major database version number, and recovery is an example directory. You can customize the recovery directory name based on the actual situation. Subsequent examples will not distinguish between directory names of different versions. The actual directory name should prevail. For example, it is /var/lib/pgsql/12 for PostgreSQL 12.x.
3.Downloading Full Backup Files
3.1. Log in to the PostgreSQL console. In the instance list, click Manage in the Operation column to go to the management page.
3.2. Select the Backup and Restoration page. In the Data Backup List, choose the backup set to be restored and click Download in the Operation column.
3.3. Download the backup file from the provided VPC address or public network address.
If downloading the backup using the VPC network address, the cloud database must be in the same VPC as the CVM. Execute the following command to download the backup to the pre-created recovery directory on the CVM. For example, use the /var/lib/pgsql/16/recovery directory. Among them, file_name is a custom file name provided by the user, and download_address is the download address provided by the system.
[root@VM-10-5-tencentos postgresql-16.8]# wget -O /var/lib/pgsql/16/recovery/file_name.tar.zst "https://postgres-backup-gz-******.cos.ap-guangzhou.myqcloud.com/pgsql/1030559/data/20**-**-**/automatic-**********.tar.zst?q-sign-algorithm=sha1&q-ak=AKIDjHZcZJpqnqiL0jP4awHZg6McnqiYIwNZ&q-sign-time=1746776185%3B1746819385&q-key-time=1746776185%3B1746819385&q-header-list=host&q-url-param-list=&q-signature=68309d4bbc1bea30fef07776a2aa9fd699c19aa9"
If you choose to download the backup file locally, after downloading, you need to upload the backup file to the pre-created recovery directory on the CVM. For example, use the /var/lib/pgsql/16/recovery directory. For specific operation methods, see How to Copy Local Files to CVMs.
After the backup is downloaded or uploaded, query whether the backup file is successfully placed in the specified directory through the following command:
[root@VM-10-5-tencentos postgresql-16.8]# ls -lh /var/lib/pgsql/16/recovery
total 3952-rw-r--r-- 1 root root 4045802 May  7 20:42 manual-20250507204222.tar.zst
4.Decompressing Full Backup Files
Decompressing backup files requires the zstd decompression tool. You can query whether this tool exists in the current CVM through the following command.
[root@VM-10-5-tencentos postgresql-16.8]# zstd –version
*** zstd command line interface 64-bits v1.4.4, by Yann Collet ***
If the version number information is displayed, it means the zstd decompression tool has been installed. If other information is prompted, the zstd decompression tool is not installed in the current CVM. Execute the following command to install.
[root@VM-10-5-tencentos postgresql-16.8]# sudo yum install epel-release
[root@VM-10-5-tencentos postgresql-16.8]# sudo yum install zstd
After installation, execute the following command to decompress the full backup file in the recovery directory.
[root@VM-10-5-tencentos postgresql-16.8]# cd /var/lib/pgsql/16/recovery
[root@VM-10-5-tencentos recovery]# tar -I zstd -xvf file_name.tar.zst
After decompression, execute the following command to view the extracted files:
[root@VM-10-5-tencentos recovery]# ls -lh
total 4.0M
-rw------- 1 postgres postgres  225 May 7 20:42 backup_label
-rw------- 1 postgres postgres  225 May 7 20:31 backup_label.old
drwx------ 6 postgres postgres 4.0K May  7 21:13 base
-rw------- 1 postgres postgres   56 May 7 20:31 current_audit_logfiles
-rw------- 1 postgres postgres   35 May 7 20:31 current_logfiles
drwx------ 2 postgres postgres 4.0K May  7 21:13 global
-rw-r--r-- 1 root     root    3.9M May  7 20:42 manual-20250507204222.tar.zst
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_commit_ts
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_dynshmem
-rw------- 1 postgres postgres  308 May 7 20:31 pg_hba.conf
-rw------- 1 postgres postgres 2.6K May  7 20:31 pg_ident.conf
drwx------ 4 postgres postgres 4.0K May  7 20:31 pg_logical
drwx------ 4 postgres postgres 4.0K May  7 20:31 pg_multixact
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_notify
drwx------ 2 postgres postgres 4.0K May  7 20:42 pg_replslot
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_serial
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_snapshots
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_stat
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_stat_tmp
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_subtrans
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_tblspc
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_twophase
-rw------- 1 postgres postgres    3 May 7 20:31 PG_VERSION
drwx------ 3 postgres postgres 4.0K May  7 21:13 pg_wal
drwx------ 2 postgres postgres 4.0K May  7 20:31 pg_xact
-rw------- 1 postgres postgres 3.2K May  7 20:31 postgresql.conf
-rw------- 1 postgres postgres    0 May 7 20:31 standby.signal
-rw------- 1 postgres postgres    0 May 7 20:42 tablespace_map
-rw------- 1 postgres postgres.   2 May 7 20:31 TENCENTDB_RELEASE
5.Removing Unnecessary Temporary Files
Execute the following command to remove unnecessary temporary files.
[root@VM-10-5-tencentos recovery]# rm -rf backup_label
6.Modifying the Configuration File
Execute the following command, and use the vi editor to modify the configuration file postgresql.conf.
[root@VM-10-5-tencentos recovery]# vi postgresql.conf
After command execution, enter the content page of the file, and press the i key to proceed with editing.
6.1. Find the following content in the file, add # at the beginning of each row to make it a comment. If any appears repeatedly, comment out all of them.
pg_stat_statements.track
synchronous_standby_names
extension_blacklist
archive_mode
basebackup_exclude_paths
tencentdb_syscache_max_num
shared_preload_libraries
tencentdb_relcache_max_num
archive_command
disable_dblink_connect_to_other
tencentdb_az_five
tencentdb_relcache_evict_num
pg_stat_statements.max
soft_limit_connections
tencentdb_syscache_evict_num
tencentdb_enable_trusted_extension
synchronous_commit
tencentdb_enable_superuser_unsafe_behaviour
tencentdb_enable_copy_to
local_preload_libraries
Note:
Note that you must comment out the line include = 'standby.conf'.
6.2. Change log_destination = 'csvlog,auditlog' to log_destination = 'csvlog'.
log_destination = ‘csvlog’
6.3. Find port in the file and change its value to 5433 to avoid conflict with the primary instance port.
port = '5433'    ## Change the value of the port parameter to 5433
6.4. Add the following content at the end of the file, indicating that the strong sync mode is no longer in use.
synchronous_commit = local
synchronous_standby_names = ''
After modification, press the esc key to exit edit mode, then enter :wq to save changes and exit the file.
7.Using the Root User to Change Folder Permissions
chmod 0700 /var/lib/pgsql/16/recovery
chown postgres:postgres /var/lib/pgsql/16/recovery -R
After modification, you can enter the following commands to view the changes. Among them, the third column returned is the file permission owner, which should display as postgres after changing.
[root@VM-10-5-tencentos recovery]# ls -al
total 4064
drwx------ 19 postgres postgres    4096 May 8 09:43 .
drwxr-xr-x  3 root    root        4096 May  7 20:44 ..
-rw-------  1 postgres postgres     225 May 7 20:42 backup_label
-rw-------  1 postgres postgres     225 May 7 20:31 backup_label.old
drwx------  6 postgres postgres    4096 May 7 21:13 base
-rw-------  1 postgres postgres      56 May 7 20:31 current_audit_logfiles
-rw-------  1 postgres postgres      35 May 7 20:31 current_logfiles
drwx------  2 postgres postgres    4096 May 7 21:13 global
-rw-r--r--  1 postgres postgres 4045802 May  7 20:42 manual-20250507204222.tar.zst
drwx------  2 postgres postgres    4096 May 7 20:31 pg_commit_ts
drwx------  2 postgres postgres    4096 May 7 20:31 pg_dynshmem
-rw-------  1 postgres postgres     308 May 7 20:31 pg_hba.conf
-rw-------  1 postgres postgres    2640 May 7 20:31 pg_ident.conf
drwx------  4 postgres postgres    4096 May 7 20:31 pg_logical
drwx------  4 postgres postgres    4096 May 7 20:31 pg_multixact
drwx------  2 postgres postgres    4096 May 7 20:31 pg_notify
drwx------  2 postgres postgres    4096 May 7 20:42 pg_replslot
drwx------  2 postgres postgres    4096 May 7 20:31 pg_serial
drwx------  2 postgres postgres    4096 May 7 20:31 pg_snapshots
drwx------  2 postgres postgres    4096 May 7 20:31 pg_stat
drwx------  2 postgres postgres    4096 May 7 20:31 pg_stat_tmp
drwx------  2 postgres postgres    4096 May 7 20:31 pg_subtrans
drwx------  2 postgres postgres    4096 May 7 20:31 pg_tblspc
drwx------  2 postgres postgres    4096 May 7 20:31 pg_twophase
-rw-------  1 postgres postgres       3 May 7 20:31 PG_VERSION
drwx------  3 postgres postgres    4096 May 7 21:13 pg_wal
drwx------  2 postgres postgres    4096 May 7 20:31 pg_xact
-rw-------  1 postgres postgres    3276 May 7 21:35 postgresql.conf
-rw-------  1 postgres postgres       0 May 7 20:31 standby.signal
-rw-------  1 postgres postgres       0 May 7 20:42 tablespace_map
-rw-------  1 postgres postgres       2 May 7 20:31 TENCENTDB_RELEASE
8.Use the incremental backup file (optional).
After the previous steps, the content of the restored database is the content of the full backup database. The backup methods of TencentDB for PostgreSQL include full backup and incremental backup. For details, see Backup Principles and Solutions.
The format of full backups differs from that of incremental backup files, and their recovery methods also vary. If you wish to restore data from incremental backup files to a CVM, you need to complete this step.
If you skip this step, the content of the restored database will be the content of the database when the full backup started.
For example, if a full backup was performed at 12:00 and the database is restored using this full backup file, and then all xlog files from 12:00 to 13:00 are placed in the pg_wal folder, the database will be restored to the data content at 13:00.
Note:
When the PostgreSQL version is 9.x, the folder path for placing xlog files is /var/lib/pgsql/9.x/recovery/pg_xlog.
8.1. Select the Backup and Restoration page. In the Log Backup List, select the log backup set to be restored and click Download in the Operation column.
Similar to a full backup file, you can directly download the file to the pg_wal directory on the CVM or download it to local and then upload it to the pg_wal directory under the recovery directory on the CVM.
If you download the backup via the VPC network address, the cloud database (CDB) must be in the same VPC as the CVM. Run the following command to download the backup to the pg_wal directory under the recovery directory.
[root@VM-10-5-tencentos postgresql-16.8]# wget -O /var/lib/pgsql/16/recovery/pg_wal/file_name.tar.zst "download_address"
After downloading, execute the following commands to confirm whether the file is successfully placed in the specified location.
[root@VM-10-5-tencentos recovery]# cd /var/lib/pgsql/16/recovery/pg_wal
 [root@VM-10-5-tencentos pg_wal]# ls -lh
total 33M
-rw------- 1 postgres postgres  16M May 7 20:42 000000010000000000000003
-rw------- 1 postgres postgres  16M May 7 20:42 000000010000000000000004
-rw-r--r-- 1 root     root    1.5K May  8 10:31 20250508103101_20250508103101-20250508101527-000000010000000000000005_000000010000000000000005.tar.zst
drwx------ 2 postgres postgres 4.0K May  7 21:13 archive_status
If you choose to download the file locally, after downloading, you need to upload the backup file to the pg_wal directory under the recovery directory. For specific operation methods, see How to Copy Local Files to a CVM.
8.2. Decompress the incremental backup files into the pg_wal folder to get xlog files.
[root@VM-10-5-tencentos pg_wal]# tar -I zstd -xvf file_name.tar.zst
000000010000000000000005
Execute the following command to view the decompression result.
[root@VM-10-5-tencentos pg_wal]# ls -lh
total 49M
-rw------- 1 postgres postgres  16M May 7 20:42 000000010000000000000003
-rw------- 1 postgres postgres  16M May 7 20:42 000000010000000000000004
-rw------- 1     1003 users     16M May 8 10:31 000000010000000000000005
-rw-r--r-- 1 root     root    1.5K May  8 10:31 20250508103101_20250508103101-20250508101527-000000010000000000000005_000000010000000000000005.tar.zst
drwx------ 2 postgres postgres 4.0K May  7 21:13 archive_status
9. Start PostgreSQL as the postgres user.
/usr/local/pgsql/bin/pg_ctl start -D /var/lib/pgsql/16/recovery -l logfile
10. Log in to the database for verification.
10.1. Verify whether the database is running.
/usr/local/pgsql/bin/pg_ctl status -D /var/lib/pgsql/16/recovery
If a "server is running" message is displayed, it indicates that the database is running.
﻿
﻿
﻿
10.2. Log in to the database.
[postgres@VM-0-5-tencentos recovery]$ /usr/local/pgsql/bin/psql -h127.0.0.1 -p 5432 -Udbadmin -dpostgres
psql (16.0)
Type "help" for help.
﻿
postgres=> 
Manually Exporting Data for Restoration
You can also manually export backup data and then restore it on the CVM. This scheme is applicable to both Windows and Linux regardless of the file system where physical files reside.
Note:
It is recommended not to use the postgres database as the target database.
Note: It is recommended to use a newly created database on the target side to import data.
If you use a database with existing data on the target side to import, it may fail due to object conflict.
1. Dump data from the CVM
The command format is: pg_dump -h <host> -p <port> -U <username> -Fc <dbname> <dumpdir>. For more usage instructions, refer to the official documentation for pg_dump.
Parameter
Description
host
The connection address of the TencentDB for PostgreSQL instance.
port
The port of the TencentDB for PostgreSQL instance.
username
The account name of the TencentDB for PostgreSQL instance.
-Fc
Output format, which is suitable for pg_restore for restoration.
dbname
The name of the database to be exported.
dumpdir
The path and name of the exported backup file.
For example:
pg_dump -h 10.0.13.13 -p 5432 -U dbadmin -Fc testdb > testdb_bkp.dump
When the command prompts Password:, enter the access account password, and the file will be successfully exported. You can run ll testdb_bkp.dump to ensure the file is generated.
﻿
﻿
﻿
2. Create the corresponding user in the self-built database
Connect to the self-built database on the target side, create the corresponding database account, and ensure the target account exists. An example is as follows:
[postgres@VM-0-14-tencentos root]$ psql -h127.0.0.1 -p5432 -Upostgres -dpostgres
psql (16.0)
Type "help" for help.
﻿
postgres=# \du   
                             List of roles
 Role name |                         Attributes                         
-----------+------------------------------------------------------------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS
﻿
postgres=# CREATE USER dbadmin WITH PASSWORD '123456' SUPERUSER;
CREATE ROLE
postgres=# \du
                             List of roles
 Role name |                         Attributes                         
-----------+------------------------------------------------------------
 dbadmin   | Superuser
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS
﻿
postgres=# 
The account created in the above example is a superuser. You can also grant system and object permissions to the user based on your needs.
3. Create the corresponding database in the self-built database
Log in to the database using the newly created user. If the database to be restored does not exist, create the database. An example is as follows:
[postgres@VM-0-14-tencentos root]$ psql -h127.0.0.1 -p5432 -Udbadmin -dpostgres
psql (16.0)
Type "help" for help.
﻿
postgres=# select datname from pg_database;
  datname  
-----------
 template1
 template0
 postgres
(3 rows)
﻿
postgres=# create database testdb;
CREATE DATABASE
postgres=# select datname from pg_database;
  datname  
-----------
 template1
 template0
 postgres
 testdb
(4 rows)
﻿
postgres=#   
4. Restore the data on the CVM
The command format is: pg_restore -h <host> -p <port> -U <username> -d <dbname> <dumpdir> -c. For more usage guidelines, refer to the official documentation for pg_restore.
Parameter
Description
host
The connection address of the self-built PostgreSQL instance.
port
The port of the self-built PostgreSQL instance.
username
The account name of the self-built PostgreSQL instance.
dbname
The name of the database to be imported.
dumpdir
The path and name of the backup file to be imported.
-c
-c is an optional parameter, indicating that the relevant data in the target database will be cleared before data restoration.
For example:
pg_restore -h 127.0.0.1 -p 5432 -U dbadmin -d testdb testdb_bkp.dump -c
5. Log in to the database to verify the data
Log in to the database using the newly created user and check whether the data has been restored. An example is as follows:
[postgres@VM-0-14-tencentos root]$ psql -h127.0.0.1 -p5432 -Udbadmin -dpostgres
psql (16.0)
Type "help" for help.
﻿
postgres=# \c testdb
You are now connected to database "testdb" as user "dbadmin".
testdb=# SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
 table_name 
------------
 sbtest1
 sbtest10
 sbtest2
 sbtest3
 sbtest4
 sbtest5
 sbtest6
 sbtest7
 sbtest8
 sbtest9
(10 rows)
﻿
testdb=# 

Deleting Backup

Last updated：2025-08-14 16:41:45

This document will describe how to delete backups and how to modify the expiration time of backups.
Note:
To ensure the continuity of data recovery within 7 days, automatic backups and log backup sets from the past 7 days are undeletable.
Manually backed up data, automatic backups, and log backup sets that exist for more than 7 days can be deleted. Data cannot be recovered after deletion.
Note that after automatic backups and log backup sets are deleted, the continuity between backup data is compromised, which can cause the inability to restore to a specified time point, i.e., time point recovery (PITR) cannot be performed.
Directions
1. Log in to the TencentDB for PostgreSQL console, select a region, and click an Instance ID to access the instance management page.
2. Navigate to the Backup and Restoration page, and in the Data Backup List or Log Backup List, locate the Operation column and click Delete.
﻿
3. A pop-up notification will display the backup file name. The file suffix indicates the time point when the backup was generated. Based on this time, you can determine the backup file to be deleted and click OK.
﻿
Set Backup Expiration Time
The system sets the backup expiration time. Backups older than this time will be automatically deleted and cannot be downloaded or restored. The system default value is 7 days. You can choose one of the following methods to modify the expiration time:
Modify Separately
If you only want to change the duration of a specific backup file, you can click on the 
﻿
 of the backup expiration time on the Backup and Restoration tab in instance management.
﻿
In the pop-up dialog box, select the backup expiration time and click OK.
﻿
Modification of Retention Time Configuration
If you wish to uniformly modify the duration of backup files' existence, you can click Auto-Backup Settings on the Backup and Restoration tab in instance management. You can modify the backup retention days, with a supported range of 3-1830 days. Backup files generated after the configuration modification will adopt the new retention time.
Note:
Modification of retention time does not affect generated backup files. If you need to modify the retention time of generated backup files, please see Modify Separately.
﻿
Additionally, if you wish to permanently save the backup file, you can directly click Manual Backup to back up the current database data. Data from manual backups will be continuously stored.

Viewing Backup Space

Last updated：2025-07-22 20:25:30

Overview
For instances of dual-server high-availability edition, the backup space occupied by TencentDB for PostgreSQL instance backup files is allocated by region. It is equivalent to the total storage capacity used by all database backups in a region, including automatic data backups, manual data backups, and log backups. Increasing manual backup frequency will use more database backup space.
Viewing the backup space
1. Log in to the TencentDB for PostgreSQL console and select Database Backup on the left sidebar.
2. Select a region at the top to view its backup information on the Overview tab, including total backup and backup statistics.
Total Backup: This section displays the size and quantity of all backups, data backups, and log backups as well as used free/paid space.
Note:
Green: The total backup space used does not exceed the free tier.
Orange: The total backup space used has exceeded the free tier and incurred fees. For more information, see Backup Space Billing.
Real-time Backup Statistics: Displays the instance ID/name, instance status, utilized free space, utilized paid space, backup space, data backup size and count, log backup size and count, automatic backup size and count, and manual backup size and count for instances within the specified region.
3. Select Backup List at the top, where the backup list is divided into data backups and log backups. In the instance list, click the instance ID to enter the Instance Details page. The backup list supports filtering by time period and fuzzy search by instance ID/name.
﻿
Data Backup List
Backups can be sorted by task start time, task end time, or backup size.
Click Details in the Operation column to enter the Backup and Restoration tab, where you can click Download to download backups.
Note:
When a monthly subscribed instance or a pay-as-you-go instance is terminated, the system will provide you with an additional "final" full physical backup to avoid nonrecovery events due to misoperation. The "final" backup capacity is not included in the backup space statistics, hence no fees are charged. You can download it in the data backup list. The "final" physical backups are automatically deleted seven days after the instance is terminated.
Log Backup List
Backups can be sorted by log data start time or end time and backup size.
Click Details in the Operation column to enter the Backup and Restoration tab, where you can click Download to download logs and click Delete to delete logs.
Note:
A log cannot be recovered once deleted. Proceed with caution.
Free tier
TencentDB for PostgreSQL will start billing for backup space soon. During the beta test of backup billing, the free backup space is the sum of the storage space of all the primary instances in the corresponding region multiplied by 700%. After the backup billing officially starts, the free backup space will be the sum of the storage space of all the primary instances in the corresponding region multiplied by 100%. For more information, see Backup Space Billing.
FAQs
How will I be charged for backup space beyond the free tier? How can I reduce the costs of backup space?
For more information, see Backup Space Billing.

Setting Backup Download Rules

Last updated：2025-08-14 16:46:26

By default, you can download backup files of TencentDB for PostgreSQL instances over public or private network. To limit the download, you can adjust backup download settings. This document describes how to do so in the console.
1. Log in to the TencentDB for PostgreSQL console, select Database Backup on the left sidebar, and select a region at the top.
2. On the Download Settings tab, view the backup download settings and click Edit to modify them.
Note:
Download over public network is enabled by default and when it is enabled, download over private network is also allowed.
﻿
3. On the displayed page, set the download rules and click OK.
Download over public network:
Enabled: You cannot set any download rule.
Disabled: You can set the download rules by allowing or blocking specific IPs and VPCs.
Set the download rules:
If you don't specify any value, the condition won't take effect. If no IP and VPC requirements are set, there will be no limit on download over private network.
﻿
4. After completing the configuration, return to the Downloads Settings page to review the activation conditions.
﻿
﻿

Use Serverless Cloud Function to Transfer Historical Backups of PostgreSQL

Last updated：2024-03-20 15:43:50

Currently, TencentDB for PostgreSQL supports retaining backup data for 3 to 7 days. You can also transfer backup files of TencentDB for PostgreSQL to Cloud Object Storage for long-term preservation through Serverless Cloud Function.
Note:
Please ensure data pull success through strict configuration and monitoring in the Cloud Object Storage Console. Otherwise, if the backup data in the database is automatically deleted after expiration, it may result in backup data loss.
Directions
1. Sign in to the Cloud Object Storage console. Go to Application Integration > Data Backup > PostgreSQL backup, as shown in the figure below: 
﻿
2. Click Configure Backup Rules to enter the PostgreSQL Backup configuration page. Click Add Function to configure the Serverless Cloud Function to pull the data backup and log backup files of PostgreSQL instances within the specified period.
﻿
﻿
﻿
3. After configuration, you can view the list of configured backup functions on the PostgreSQL Backup Function page, as shown in the figure below: 
﻿
4. Once the function is created, you can click More > Trigger > Confirm to trigger the function execution. This function can pull the backup data of TencentDB for PostgreSQL, accessing data for up to the last 7 days.
﻿
﻿
You can also use the default settings for the system to automatically trigger function execution.
5. Once the backup data pulling is successful, click the corresponding bucket address in the Associated Bucket column to view the saved data. 
﻿
Note:
The running log of Serverless Cloud Function can be viewed in the Serverless Cloud Function Console. It is not recommended to directly modify the function for pulling backup from the Serverless Cloud Function Console.
Pulling historical backups of TencentDB for PostgreSQL may incur related costs. For specific charging details, please refer to Pay-As-You-Go, Pay-As-You-Go, and Product Pricing.
﻿

Rollback to the Original Instance

Last updated：2025-08-14 16:53:09

Note:
Rollback to the original instance supports the operation of database-level objects.
For instances of SQL Server compatible engines, the rollback of mssql_compatible databases is currently not supported.
Up to 100 databases can be selected for a single rollback task.
Rollback to the original instance allows you to restore existing database objects in the current instance to a specific point in time or backup set. It can also solve the problem of recovering accidentally deleted databases. A detailed description is provided below.
Selecting the Recovery Method and Time Point
1. Log in to the PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to access the instance management page.
2. On the instance management page, select Backup and Restoration, then click Database and Table Restoration to navigate to the recovery settings page.
﻿
3. You may opt to restore data to a specific backup set or choose to recover it to any point in time detected by the system.
Note:
The selectable time for database table recovery is strongly related to your current backup retention policy. For backup settings, refer to Automatic Backup Settings.
You can choose to recover to a specific backup set or to any point in time when the system detects data.
﻿
Selecting the Database to Recover
You can select an existing database pulled by the current system for recovery. Details are shown in the figure below:
﻿
Name after Recovery
The name of the recovered database will have a *_bak_timestamp suffix. The timestamp is a Unix timestamp when a backend task is initiated. After you submit a database table rollback task on the console or via API, the backend will initiate a rollback task within 5 minutes. For example, if the database name selected by you is dbone and the backend initiates the task at 2024-05-30 11:26:25, the new database name after the recovery task is completed will be dbone_bak_1717039585.
Handling Accidental Database Deletion
If a database is deleted due to misoperation, the database table rollback feature can resolve this problem. Since the deleted database cannot be retrieved when a task is initiated, you can start the task by adding a new database. Click Add in the figure below.
﻿
Note:
If the added database name does not exist in the selected backup set or PITR time point, an empty database will be recovered.
﻿

Backup Recovery for Deleted Instances

Last updated：2025-07-22 20:25:30

Background
For a destroyed instance from the recycle bin, you can locate the instance's backup file to restore it as a new TencentDB for PostgreSQL instance. Alternatively, you can download the backup file to restore it to a self-built PostgreSQL.
This document describes the operation of instance and method for restoring a backup file to a new TencentDB for PostgreSQL instance.
Applicable Scope
Database instances of major version 11 or higher.
Note:
Note: The TencentDB for PostgreSQL instance restored from a backup file has the same major version as the source instance, and the latest kernel minor version will be used.
Concept Introduction
A backup set refers to a collection of files generated during the database backup process, including data backup files and log backup files. The backup set files serve as the basic data source for database recovery.
The data backup file includes three types: automatic, manual, and final. Details are as follows:
Type
Source
Retention policy
Space Usage Cost
Recovery Operations
Delete Operation
auto
Automatically generated by the system.
By default, backups are retained for 7 days from the generation time. Users can also customize the setting. For details, please refer to Automatic Backup Settings.
Consistent with the instance running pricing. For details, please refer to Backup Space Billing.
Recover by backup set or time point recovery.
If a backup set contains data within 2 days, it cannot be deleted.
Manual
Users can save by themselves. For details, please refer to Data Backup.
Permanent retention.
Consistent with the instance running pricing. For details, please refer to Backup Space Billing.
Recover by backup set or time point recovery.
Self-service deletion.
Final
The instance is automatically generated by the system when it is put into the recycle bin and completely cleared upon expiration.
Retention period: 8 days from generation time.
No charge.
Recover by backup set or time point recovery.
Non-deletable, can only be automatically cleared by the system upon expiration.
Feature Introduction
Querying a Backup Set
After the instance is decommissioned from the recycle bin, you can view its data backup and log backup files on the Backups of Terminated Instances webpage. The system supports filtering specific backup sets by file creation time, instance ID, instance name, or instance IP. Log in to the TencentDB for PostgreSQL console > Database Backup page, select Backup List > Backups of Terminated Instances. The system supports quick filtering for today, yesterday, or the last 7 days. You can also customize the start and end time in the time filter box at the top right of the list to filter by "task start/end time."
﻿
Restoring a Deleted Instance
Note:
Note: When TDE is enabled for your instance, please ensure the KMS key is in normal usage status. Otherwise, keys cannot be obtained from KMS, which will cause the recovery feature to fail.
1. Log in to the TencentDB for PostgreSQL console > Backup Database webpage, select Backup List > Terminated Instance Backup. In the target instance's Operation column, click Restore.
﻿
2. Select database parameters, then click Purchase Now to pay.
Recovery method
By time point: Restore by specifying a time point within the traceable time range of the backup file.
Note:
Note: The recoverable time point when selecting point-in-time recovery depends on the log backup files you reserved. After deletion of log backup files, the time points afterward cannot be recovered.
﻿
By backup set: Select the time node when the backup file was generated to restore.
﻿
Note:
Recovered instances:
- The major kernel version matches the original instance, and the latest minor kernel version will be used.
Instance location, userName, user password match the source instance.
After instance recovery, the backup file of the terminated instance still exists.
Download Backup File Manual Self-Build Restore
If you wish to migrate data to a Cloud Virtual Machine (CVM), the system supports downloading backup files of terminated instances for users to manually rebuild the database locally.
1. Log in to the TencentDB for PostgreSQL console > Backup Database webpage, select Backup List > Backup of Terminated Instance. Click 
﻿
 under the instance backup list column.
﻿
2. For the required backup file, click Download in the Operation column to perform manual data recovery. For details, please refer to Restore PostgreSQL Data on CVM.
﻿
Deleting Backup Files
For instances decommissioned from the recycle bin, if their backup sets still exist, you can delete these backup sets if they are no longer needed. Log in to the TencentDB for PostgreSQL console > Database Backup page, select Backup List > Backups of Terminated Instances, then choose the backup files to delete. If no deletion is required, the backup sets will be automatically deleted by the system upon expiry.
Note:
To ensure the recovery duration of your terminated instance, the system will initiate a final backup and generate a final backup set when the instance goes offline in the Recycle Bin. The final backup set will be retained for 8 days with no charge and is non-deletable.
To ensure data recoverability, backup sets generated within two days are currently undeletable.

Data Migration

DTS-Based Logical Migration

Instructions

Last updated：2024-11-04 10:04:48

Category
Description
Supported versions
1. Source database
Self-built databases PostgreSQL 10-16
Third-party cloud vendors 10-16
Alibaba Cloud RDS PostgreSQL
AWS RDS PostgreSQL
Huawei Cloud RDS for PostgreSQL
TencentDB for PostgreSQL 10-16 (Migration within the same root account/Migration between different root accounts)
2. Target database
TencentDB for PostgreSQL 10-16
Impact on the source database
1. During full data migration, Data Transfer Service (DTS) consumes certain source instance resources, which may increase the load and pressure of the source database. If your database configuration is low, we recommend you perform the migration during off-peak hours.
2. During the actual migration process, the rate can be influenced by factors such as the read performance of the source instance, network bandwidth between the source and target instances, and the specifications and performance of the target instance. The migration concurrency is determined by the number of cores of the target instance. For example, if the target instance has 2 cores, the concurrency will be 2.
Migration object
Interrelated data objects need to be migrated together; otherwise, the migration will fail. Common association relationships include: views referencing tables, views referencing views, storage procedures/functions/triggers referencing views/tables, and table association through primary and foreign keys.
Source database requirements
When Full + Incremental Migration is selected as the migration type, the tables in the source database must have primary keys; otherwise, data inconsistency between the source and target databases may occur. For tables without primary keys, it is recommended to select Full Migration.
Target database requirements
If the entire instance is to be migrated, the target database must not contain users and roles with the same names as those in the source database.
Network description
1. When a migration task is configured, the source database address must use the IP address and port that can directly connect to the PostgreSQL instance. Do not use the IP address and port of proxies like pgpool.
2. To ensure migration efficiency, cross-region migration is not supported for self-built instances on Cloud Virtual Machine (CVM). If cross-region migration is needed, choose the public network access method.
Operation limits
1. During the structural migration, full migration, and incremental migration, do not perform DDL operations or Large Object operations; otherwise, data inconsistency will occur.
2. Do not modify or delete user information (including the username, password, and permissions) and port numbers in the source and target databases during migration.

Operation Guide

Last updated：2024-11-04 10:04:25

Overview
This document describes how to use the Data Transfer Service (DTS) logical migration feature to migrate data from PostgreSQL to TencentDB for PostgreSQL.
Preparations
1. Read the Logical Migration Instructions carefully to understand feature restrictions and precautions.
2. Establish an access channel between DTS and databases in advance according to the access type you need. For details, see Overview of Preparations Related to Network.
Self-built databases in Internet Data Center (IDC)/Databases of other cloud vendors: Select public network, Direct Connect, Virtual Private Network (VPN) access, or Cloud Connect Network (CCN) as the access method.
When migrating via the public network, ensure that the source instance service is accessible under the public network environment and that the public network connection remains stable. Network fluctuations or failures may cause the migration to fail. If the migration fails, a new migration task will need to be initiated.
Self-built databases on Cloud Virtual Machine (CVM): Select Self-Build on CVM as the access method.
TencentDB instances: Select Database as the access method.
3. The permissions required for the source database are as follows:
If the source database is a PostgreSQL database other than TencentDB for PostgreSQL, the source database account must have replication permissions; otherwise, the verification will fail.
If the source database is TencentDB for PostgreSQL, the source database account must be the initialization user specified when the TencentDB instance is created.
If you do not have permissions for some tables or objects, you can use a high-privilege user account to execute the following example statements to grant permissions for the objects respectively:
grant select on table table name to username;
grant select on SEQUENCE sequence name to username;
grant connect on database database name to username;
grant select on large object large object OID to username;
GRANT USAGE ON SCHEMA schema name to username;
4. The permissions required for the target database are as follows:
The target database account must be the initialization user specified when the TencentDB instance is created.
If the database to be migrated exists in the target database instance but the database's owner is not the current migration user, you can execute the following statement to grant the database to the migration user:
alter database database name owner to migration user;
If the migration user (the account executing a migration task) is not a pg_tencentdb_superuser role user, during verification, you will receive an error message saying "Target instance permission check failed, unable to get Schema List." In this case, use the following statement to grant initialization user permissions to the migration user.
grant pg_tencentdb_superuser to migration user;
Directions
1. (Optional) When performing full + incremental migration using PostgreSQL 9.4, 9.5, or 9.6 as the source database, you need to refer to the following guide to install the tencent_decoding plugin. Skip this step for other scenarios.
1.1 Download the corresponding plugin based on the system architecture of the server where the source database is located.
Only system architectures x86_64 and AArch64 are supported.
The plugin version must be consistent with the PostgreSQL version.
The Glibc version must meet the following requirements: For x86_64 systems, it should not be earlier than version 2.17 - 323, and for AArch64 systems, it should not be earlier than version 2.17 - 260.
Check the Glibc version on a Linux system:
RHEL/CentOS: rpm -q glibc
Check the Glibc version on other operating systems (such as Debian, Ubuntu, and SUSE):
ldd --version | grep -i libc
Download address: x86_64 9.4, x86_64 9.5, x86_64 9.6, AArch64 9.4, AArch64 9.5, AArch64 9.6.
1.2 Place the downloaded tencent_decoding.so file in the lib folder of the PostgreSQL process directory. You do not need to restart the instance.
2. Log in to the DTS console, select Data Migration in the left sidebar, and click Create Migration Task to enter the Create Migration Task page.
3. On the Create Migration Task page, select the source instance type and region, target instance type and region, and specification, and then click Buy Now.
Configuration Item
Description
Source Instance Type
Choose according to your source database type. It cannot be modified after purchase. This example uses "PostgreSQL".
Source Instance Region
Select the region of the source database. If the source database is a self-built one, select a region nearest to it.
Target Instance Type
Choose according to your target database type. It cannot be modified after purchase. This example uses "PostgreSQL".
Target Instance Region
Select the region of the target database.
Specification
Select the specification of a migration link according to your business conditions. For the performance and billing details of different specifications, see Billing Overview.
4. On the Set Source and Target Databases page, complete task settings, source database settings, and target database settings. Once the connectivity test between the source and target databases succeeds, click Create.
Note:
If the connectivity test fails, troubleshoot and fix the issues as prompted in Fixing Instructions, and then try again.
﻿
Setting Type
Configuration Item
Description
Task Configuration
Task Name
Set a business-significant name for easy task identification.
﻿
Running Mode
Immediate execution: Start a task immediately after passing task verification.
Scheduled execution: Set a task execution time, and the task will start when the time is reached.
﻿
Tag
Tags are used to manage resources by category from different dimensions. If the existing tags do not meet your requirements, go to the console to manage the tags.
Source Database Settings
Source Database Type
The source database type selected at the time of purchase, which cannot be modified.
﻿
Region
The source database region selected at the time of purchase, which cannot be modified.
﻿
Access Type
Choose according to your scenario. This example uses "Database". For preparation work for different access types, refer to Overview of Preparations Related to Network.
To ensure migration efficiency, cross-region migration is not supported for self-built instances on CVM. If cross-region migration is needed, choose the public network access method.
Public Network: The source database can be accessed via a public IP address. When migrating via the public network, ensure that the source instance service is accessible under the public network environment and that the public network connection remains stable. Network fluctuations or failures may cause the migration to fail. If the migration fails, a new migration task will need to be initiated.
Self-Build on CVM: The source database is deployed on a Tencent CVM. To ensure migration efficiency, cross-region migration is not supported for self-built instances on CVM. If cross-region migration is needed, choose the public network access method.
Direct Connect: The source database can be connected to Tencent Virtual Private Cloud via Direct Connect.
VPN Access: The source database can be connected to Tencent Virtual Private Cloud via VPN Connections.
Database: The source database is a TencentDB instance.
CCN: The source database can be connected to Tencent Virtual Private Cloud via Cloud Connect Network.
﻿
Cross-/Intra-Account
Intra-account: The source database instance and the target database instance belong to the same Tencent Cloud root account.
Cross-account: The source database instance and the target database instance belong to different Tencent Cloud root accounts. The following is an example of migration within the same account. For cross-account migration guidance, refer to Cross-Account TencentDB Instance Migration.
﻿
Database Instance
Select the instance ID of the source PostgreSQL database.
﻿
Account
The account of the source PostgreSQL database, which must have the required permissions.
﻿
Password
The password of the source PostgreSQL database account.
Target Database Settings
Target Database Type
The target database type selected at the time of purchase, which cannot be modified.
﻿
Region
The target database region selected at the time of purchase, which cannot be modified.
﻿
Access Type
Choose according to your scenario. This example uses "Database" by default.
﻿
Database Instance
Select the instance ID of the target database.
﻿
Account
The account of the target database, which must have the required permissions.
﻿
Password
The password of the target database account.
5. On the Set migration options and select migration objects page, configure the migration type and objects and click Save.
﻿
Configuration Item
Description
Migration Type
Choose according to your scenario.
Structural migration: Migrate structured data such as databases and tables.
Full migration: Migrate the entire database. The migrated data includes only the existing data of the source database when a task is initiated and does not include the incremental data written to the source database after a task is initiated.
Full + Incremental migration: The migrated data includes the existing data of the source database when a task is initiated as well as the incremental data written to the source database after a task is initiated. If data is being written to the source database during migration, and you want to smoothly migrate the data in a non-stop manner, select this option.
Migration Object
Entire instance: Migrate the entire instance, excluding system databases such as system objects in PostgreSQL. However, roles and user metadata definitions will be migrated.
Specify object: Migrate specified objects.
Specify object
Select the objects to be migrated in Source Database Object and move them to the Selected Object box.
6. On the task verification page, verify the task. After the task passes verification, click Start Task.
 If the verification fails, refer to Verification Failure Handling to fix the issues and then reinitiate the verification task.
Failed: indicates that a verification item failed the check, the task is blocked, and you need to fix the issue and execute the verification task again.
Warning: indicates that a verification item does not fully meet the requirements but the task can proceed, impacting the business to some extent. You need to decide based on the prompt whether to ignore the warning or fix the issue and continue.
﻿
7. Return to the data migration task list. The task enters the Ready to Run state. After 1 to 2 minutes, the data migration task will officially start.
Select Structural migration or Full migration: Once completed, the task will automatically end without manual intervention.
Select Full + Incremental migration: After full migration is completed, the migration task will automatically enter the incremental data synchronization phase, which will not stop automatically. You need to manually click Complete to stop the incremental data synchronization. After you click Complete, the task enters the In Progress state. Do not make any changes to the source end or the target end as the backend will automatically align some objects with the source end.
Manually complete incremental data synchronization and business cutover at appropriate time.
When a migration task is in the incremental synchronization phase without any latency, stop writing data to the source database for a few minutes.
Manually complete incremental synchronization when the data gap between the target and the source databases is 0 MB and the time latency between them is 0 seconds.
﻿
8. (Optional) If you need to view tasks, delete tasks, and perform other operations, click the corresponding task and select an action in the Operation column. For details, see Task Management.
9. When the migration task status changes to Task successful, you can proceed with the official business cutover. For more details, refer to Cutover Description.

Verification Failure Handling

Database Connection Check

Last updated：2024-12-12 20:11:49

Check Details
The source and target databases need to be properly connected; if not, a connection failure will be reported.
Cause
﻿The network or server where the source database resides has a security group or firewall configured.
﻿The source IP addresses are blocked in the source database.
﻿The network port is not opened.
The database account or password is incorrect.
Fixing Method
Follow the corresponding links in the problem cause for processing.

Dependency Check

Last updated：2024-11-04 10:07:51

Check Details
1. If Full Migration or Full + Incremental Migration is selected on the Data Transfer Service (DTS) task configuration page but no specific tables are selected for migration other than public objects, the verification task will report an error. The table objects need to be selected.
2. If views are selected but the tables that the views depend on are not selected for the migration objects, the verification task will report an error. Interrelated objects need to be migrated together.
Fixing Method
Reconfigure the DTS task. Interrelated objects need to be migrated together.

Version Check

Last updated：2024-11-04 10:09:08

Check Details
Migration Scenario
Full + Incremental migration requires both the source and target instance versions to be later than or equal to 10.0.
If the source and target instance versions are different, some special compatibility issues may arise, and a warning will be reported. Read the compatibility report for each version to check whether your business is using any incompatible features.
Synchronization Scenario
Versions earlier than PostgreSQL 10 do not support synchronization. The target instance version should be later than or equal to the source instance version during data synchronization.
If the versions are different, some special compatibility issues may arise, and a warning will be reported. Read the compatibility report for each version to check whether your business is using any incompatible features.
Fixing Method
Check the source and target databases according to the version requirements. If the source or target database version is not supported, upgrade the target instance version or use a database instance of a later version.

Incremental Migration Check

Last updated：2024-11-04 10:50:08

Check Details
If you select incremental migration as the migration type, you need to check the following conditions; otherwise, the verification will fail.
The wal_level of the source database must be logical.
The max_replication_slots and max_wal_senders parameters in the source database must be greater than the total number of databases to be migrated (retain extra connections).
The persistence attribute of the tables to be migrated in the source database must be p (permanent tables); otherwise, replication is not supported, and hence logical migration is not possible.
The tables to be migrated should not include unlogged tables; otherwise, they cannot be migrated.
It is recommended to migrate tables with primary keys. Otherwise, inconsistent data results may occur. You are advised not to migrate tables without primary keys.
If the table to be migrated has no primary key and does not contain a replica identity (that is, the REPLICA IDENTITY attribute is set to NOTHING), the verification task will report a warning.
If the table to be migrated has no primary key and includes field types that cannot use the = operator (json/point/polygon/txid_snapshot/xml), the verification will fail. You need to modify the table without a primary key as prompted or deselect the primary key table option; otherwise, the task cannot proceed.
Fixing Method
Modifying the wal_level/max_replication_slots/max_wal_senders Parameters
The method to modify the parameters wal_level, max_replication_slots, and max_wal_senders is as follows.
1. Log in to the source database.
Note:
If the source database is a self-built database, you need to log in to the server where the database runs and go to the main directory of the database data, which is usually $PGDATA.
If the source database is in another cloud, modify the parameters as requested by the corresponding cloud vendor.
If you need to modify the parameters of the target instance, submit a ticket through Online Support for assistance.
2. Usually, open the postgresql.conf file and modify the corresponding parameters.
wal_level = logical
max_replication_slots = 10  //Modify according to actual needs.
max_wal_senders = 10  //Modify according to actual needs.
3. After the modification is completed, restart the database instance.
4. Log in to the database instance and run the following command to check whether the parameters are correctly set:
postgres=> select name,setting from pg_settings where name='wal_level';
name    | setting 
-----------+---------
 wal_level | logical
(1 row)
postgres=> select name,setting from pg_settings where name='max_replication_slots';
      name          | setting 
-----------------------+---------
 max_replication_slots | 10
(1 row)
postgres=> select name,setting from pg_settings where name='max_wal_senders';
   name       | setting 
-----------------+---------
 max_wal_senders | 10
(1 row)
5. Perform the verification task again.
Modifying the REPLICA IDENTITY Attribute of the Table to Be Migrated
It is generally not recommended to migrate tables without primary keys, as this may lead to data inconsistencies. If the table to be migrated has no primary key and does not contain a replica identity (that is, the REPLICA IDENTITY attribute is set to NOTHING), the verification task will report a warning.
If a warning is reported, you are advised to modify the attribute parameters of the table as follows.
ALTER TABLE schemaName.tableName REPLICA IDENTITY FULL;

Structure Compatibility Check

Last updated：2024-11-04 10:16:55

Check Details
If the target database version is 12 or later and the table to be migrated contains three data types: abstime, reltime, and tinterval, the verification task will report an error.
The data types abstime, reltime, and tinterval are old time and date types that have been deprecated in the latest PostgreSQL version. It is recommended to replace them with the following types:
abstime: It can be replaced with the timestamp or timestamp with time zone type. These types provide a broader range of capabilities for representing dates and times.
reltime: It can be replaced with the interval type. The interval type is used to represent time intervals and can include units such as years, months, days, hours, minutes, and seconds.
tinterval: It can be replaced with the tsrange or tstzrange type. These types are used to represent time ranges and can include start and end times.
Fixing Method
The modification method for the three data types abstime, reltime, and tinterval is similar. First, create a column, convert the old data format to the new data format, and store it in the new column. After verifying the new column data is correct, delete the old column. Finally, if needed, rename the new column to the name of the old column.
The following example shows how to modify abstime to timestamp.
1. In the table where the verification task reports an error, add a new column of the timestamp type.
ALTER TABLE your_table ADD COLUMN new_column TIMESTAMP;
2. Convert the data in the abstime column to the timestamp type and store the result in the new column.
UPDATE your_table SET new_column = your_abstime_column::TIMESTAMP;
3. Verify whether the data in the new column is correct.
SELECT * FROM your_table;
4. If the data in the new column is correct, you can delete the old abstime column.
ALTER TABLE your_table DROP COLUMN your_abstime_column;
5. If needed, you can rename the new column to the old column's name.
ALTER TABLE your_table RENAME COLUMN new_column TO your_abstime_column;

Structure Conflict Check

Last updated：2024-11-04 10:18:12

Check Details
In the PostgreSQL migration scenario, the target instance cannot have objects with the same name as those in the source database.
If there are tables and views with the same name as the objects to be migrated at the target end, the task reports an error.
If there are functions, triggers, and indexes with the same name as the objects to be migrated at the target end, the task reports a warning.
During PostgreSQL instance migration, the target instance must be empty.
Fixing Method
If a conflict is detected, delete the conflicting content or rename the conflicting object, and then verify it again.

Account Conflict Check

Last updated：2024-11-04 10:19:28

Check Details
In migration scenarios, check whether the target database user conflicts with the source database user.
Fixing Method
In full instance migration, if the target instance has the same account as that in the source instance, you need to delete the account with the same name in the target instance.
If the account in the target database is an initialization account, use the initialization account to log in to the database and run the following statements:
create user new user with password 'password';
grant pg_tencentdb_superuser to new username;
alter user new user with CREATEDB;
alter user new user with CREATEROLE;
If the account in the target database is a new user, use the newly created user to log in to the database and delete the conflicting user.
drop user conflicting user;
# If the conflicting user has resource dependencies, run the following statement to modify the owner of the resources first (with a table as an example below):
alter table table name owner to new user;
After the conflicting user is deleted, perform the verification task again.

Parameter Configuration Conflict Check

Last updated：2024-11-04 10:24:36

Check Details
1. Check the following parameter values of the source and target databases. If a parameter has different values in the source database and target database, the verification task will report a warning. The warning will not block the migration task but may impact the business. Evaluate and decide whether to modify the parameters.
TimeZone, lc_monetary, lc_numeric, array_nulls, server_encoding, DateStyle, extra_float_digits, gin_fuzzy_search_limit, xmlbinary, and constraint_exclusion.
When parameters are not set consistently, the specific impacts are as follows.
TimeZone: sets the instance time zone. If this parameter has different values, data may be incorrect after migration.
lc_monetary: sets the instance currency mode. If this parameter has different values, currency numbers may be incorrect after migration.
lc_numeric: sets the instance numeric mode. If this parameter has different values, data may be incorrect after migration.
array_nulls: sets whether arrays can be empty. If this parameter has different values, data inconsistency may occur, and some data may fail to be migrated.
server_encoding: sets the instance character set. If this parameter has different values, garbled characters may be present in the stored data.
DateStyle: sets the date format. If this parameter has different values, data migration may fail.
extra_float_digits: sets the output precision of floating-point values. If this parameter has different values, data precision will be affected. In high-precision database use cases, data inconsistency will occur after migration.
gin_fuzzy_search_limit: sets a soft upper limit on the set size returned by the GIN index. If this parameter has different values, data display inconsistency will occur after migration.
xmlbinary: sets the XML function conversion result. If this parameter has different values, function execution in the target database may be different from that in the source database.
constraint_exclusion: sets whether the restraints take effect. If this parameter has different values, data inconsistency may occur after migration.
2. Check whether the character set configurations of the source and target databases are inconsistent. If so, the verification task will report an error. Modify them to ensure consistency.
Fixing Method
1. Use the superuser account to log in to the source database.
2. Run the following sample statements to modify the corresponding parameters:
You can first modify the parameters in the source database. If such parameters cannot be modified, you need to modify them in the target database through Online Support.
The server_encoding parameter cannot be modified in the source database. If this parameter is abnormal, check whether it has been created in the target database. If it has been created and is inconsistent with that in the source database, a new instance must be requested. If it has not been created, refer to the following method to modify it (currently, TencentDB instances only support UTF8 and LATIN character sets).
alter system set timezone='parameter value';
alter system set lc_monetary='parameter value';
alter system set lc_numeric='parameter value';
﻿

Plugin Compatibility Check

Last updated：2024-11-04 10:24:17

Check Details
Check whether the plugins existing in the source database also exist in the target database.
If there are plugins to be migrated from the source database, and the target database lacks the permissions to create plugins, the verification task will report an error.
If there are plugins to be migrated from the source database, and the corresponding plugins are not installed on the target database, or the versions do not match, the verification task will report an error.
Fixing Method
Install the plugin of the same version on the target database as the source database, and grant the corresponding permissions for the plugin on the target database. For details, see PostgreSQL Official Guide.

Multi-Task Conflict Check

Last updated：2024-11-04 10:23:49

Check Details
In PostgreSQL synchronization tasks, ring links are not supported during task configuration. If a ring link exists, the verification task will report an error. If the source end synchronization object has multiple tasks, an alarm will be triggered. Check whether the task configurations are reasonable.
Fixing Method
Follow the interface prompts to cancel tasks that have loopback or duplicate synchronizations, and then perform the verification task again.

Long Transaction Check

Last updated：2024-11-04 10:41:06

Check Details
If there are long-running transactions in the source database, the verification task will report a warning. You can ignore the warning and continue the task, but it is recommended to handle the long transactions first before starting a Data Transfer Service (DTS) task.
Fixing Method
Process the long transactions in the source database, and then start the DTS task after the transactions have ended.

Creating a Data Consistency Check Task

Last updated：2025-04-07 16:48:07

Overview
During data consistency check, Data Transfer Service (DTS) compares the table datas in the source and target databases, providing comparison results and inconsistency details to help you quickly verify synchronization results before cutover. A data consistency check task is independent and does not affect the normal business of the source database or other DTS tasks.
Note:
Consistency check only serves as a supplementary data verification method. Before the final cutover, you should perform drills to ensure the results meet the cutover requirements.
Links currently supporting data consistency check are as follows:
 PostgreSQL > PostgreSQL
Notes and Restrictions
1. A data consistency check task may increase the load in the source database instance. Therefore, you need to perform such tasks during off-peak hours.
2. Currently, data consistency check is supported only when the migration type is Full + Incremental Migration.
3. For sampling comparison, the table to be checked must have a primary key or unique key; otherwise, it will be skipped. Row count check does not require a primary key or unique key. If a table has no primary key or unique key and the data exceeds 10,000 rows, a full comparison cannot be performed.
4. If you choose to Complete or Stop a DTS task before a data consistency check task is completed, the check task will fail.
Creating a Data Consistency Check Task
Note:
Creating a separate data verification task only supports independent check, not built-in check.
Independent check is separate from a DTS task and compares the same data blocks at the source and target ends. After the DTS task stops running, the check cannot be initiated.
An independent check task can be initiated only when the task is running and is in the incremental synchronization phase. If the task is completed, the check task cannot be initiated. You can initiate check tasks multiple times based on different cutover phases, in batches, and with different check methods.
1. Log in to the DTS console, select Data Migration in the left sidebar, and click View in the Operation column of the task list, or click the task ID directly to view task details.
2. Click Data Consistency Check to enter the task list of Data Consistency Check. Click Create Data Consistency Check Task to create a data verification task.
﻿
﻿
Configure the details of the verification task as follows:
Parameter
Description
Task Type
Independent Check: The verification service operates independently of a DTS task and can compare other data not involved in the migration.
Structure Verification
Verify the data object structures at both the source and target ends. If you have confirmed the structures are consistent, disabling structure verification can save time.
Check Object
All migration objects: Check all the objects selected in a migration task.
Custom: Choose the objects to be verified from the selected migration objects.
Comparison Type
Full comparison: Check all the data for the selected objects.
Sampling: Check the data of a certain proportion (10%, 20%, 30%, ..., 90%) for the selected objects.
Row count check: Only compare the data row count for the selected objects. In this case, even tables without primary keys can also be checked.
Thread Count
The value ranges from 1 to 8 and can be set as needed. Adding more threads can speed up the consistency check, but doing so will put more load on the source and target databases. Each added thread will require one extra CPU core.
3. After configuration, click Create and Start Consistency Check to initiate the verification task.
Viewing Data Consistency Check Results
Note:
When an inconsistency is first detected in a table during the verification task, the system will mark the comparison result as inconsistent and the task status as failed.
1. On the migration task homepage, in the Last Check Result column, you can view whether the verification result is consistent or not. Click View > Data Consistency Check to enter the verification details page.
﻿
﻿
2. Click View to check the verification result.
﻿
Summary of Data Verification Results
The summary information of the data verification results is shown in the following table:
Item
Details
Overview
Comparison Type: All are currently Independent Check.
Comparison Method: The available options are Full comparison, Sampling, and Row count check.
Structure Verification: The available options are Enabled and Disabled.
Status: The current status of the verification task, which can be Created, Awaiting Execution, Running, or Completed.
Compare Conclusion: The result of the current verification task, which can be Inconsistent or Consistent.
Thread Count: The number of threads configured for the current task.
Estimated Tables
The system's estimated total number of tables that need verification.
Checked Tables
The number of tables that have currently been successfully checked.
Inconsistent Tables
The number of tables with inconsistencies between the source and target ends among the tables that have already been checked. You can view specific inconsistent tables in Details.
Inconsistent Chunks
The number of chunks with inconsistencies between the source and target ends among the tables that have already been checked. During system verification, chunks are used for verification at both ends, with each chunk containing 10,000 rows of data.
Data Verification Result Details
PostgreSQL data verification tasks will display the following types of inconsistencies during the verification process. Below is an introduction for each type:
Inconsistency Details
This section will display detailed information about the chunks with inconsistencies in the tables that have already been checked. You can locate specific data by clicking View in the Operation column of the details list, as shown in the figure below:
﻿
﻿
Table Structure Inconsistency Details
Only tasks with structure verification enabled will display details of structure inconsistencies. During structure verification, the system will list all the details of the inconsistent table structures that have been checked, as shown in the figure below:
﻿
You can view the detailed SQL statements of structure inconsistencies by clicking Details in the Structure column of the list, as shown in the figure below:
﻿
Owner Inconsistency Details
The data verification task will list the details of tables with inconsistent owners among all the tables that have been checked, as shown in the figure below:
﻿
Unchecked Table Details
The data verification task will list the details of all the tables that have not been checked.
How It Works
Row count comparison: Check whether the numbers of rows in the source and target tables are consistent.
Sampling comparison:
Tables without a primary key or unique index cannot be sampled and will be skipped directly.
For other tables, the system will first check whether the numbers of rows in the source and target tables are consistent. If not, they will be marked as inconsistent, and the system will skip these tables and proceed with verifying other tables.
When the numbers of rows in the tables are consistent, the system will partition the table into multiple blocks according to the sampling ratio. It will randomly select rows in each block and calculate the MD5 values for both the source and target tables for comparison. Identical MD5 values indicate consistency.
Full comparison:
For tables without a primary key or unique index:
If the table has more than 10,000 rows, the system will not perform a data consistency check.
If it has fewer than 10,000 rows, the system will sort all columns and obtain all the data from the table. It will then calculate the MD5 values for both the source and target tables. Identical MD5 values indicate consistency.

Physical migration based on DTS

Configure Physical Migration Tasks

Last updated：2024-07-23 11:56:42

Physical migration employs TencentDB for PostgreSQL physical streaming replication, which is faster and more stable. This document describes how to configure a physical migration task and related precautions.
Configuring a Task
1. Log in to the TencentDB for PostgreSQL Console .
2. In the left sidebar, select Data Migration.
3. Go to the Data Migration task list. Click Create Migration Task, to set up a migration task with the source and target instance type as TencentDB for ostgreSQL.
﻿
4. After creating the migration task, go to the migration task list, click Operation > Configure, to configure the newly created task.
﻿
5. The configuration task involves three steps. Note that in the second step, the migration method needs to set to Physical migration. Select default for both migration type and migration object. Proceed to task verification afterward.
﻿
6. For system verification details and repair methods, please see Physical migration check items.
Note:
If the source instance is a self-hosted TencentDB for PostgreSQL instance, be sure that the TencentDB for PostgreSQL data directory does not contain any other self-hosted files or directories. Otherwise, the procedure failure may occur.
﻿
7. After all verifications pass, the task officially starts, and you can view the task details in the task list. The entire task involves seven steps, as shown in the figure: 
﻿
﻿
﻿
For detailed descriptions of the migration steps, see Migration steps explanation.
Migration Steps Explanation
1. Precheck
Before initiating the migration task, the system performs multiple environmental checks on the source and target instances, including the following items:
Target instance session checks: Checks if there are any user sessions on the target instance, and if yes, a system report error is raised. User sessions mainly refer to sessions initiated by accounts other than the following three types of database accounts.
postgers
repluser
Accounts starting with tencentdb_
Target instance database and table check: Checks if there are any user databases or objects on the target instance, and if yes, a system error is raised.
Target instance associated instance checks: Checks if the target instance is already associated with any RO instances, and if yes, an error is raised.
2. Data Backup
To ensure the recoverability of data on the target instance, the system first performs a full automatic backup of the target instance. By using the native TencentDB for PostgreSQL tool pg_basebackup, it sets up a standby for the source instance in the Tencent Cloud PostgreSQL environment. Then, it is ready to start the primary-standby data synchronization. TencentDB for PostgreSQL Backup space is already billed, and costs incurred beyond the instance's complimentary space will be charged. For more details on charges, please see Backup space billing explanation.
3. Full Migration
Use the TencentDB for PostgreSQL physical streaming replication to implement full synchronization between the source instance and the standby instance on the Tencent Cloud PostgreSQL.
4. Incremental Sync
Use the TencentDB for PostgreSQL physical streaming replication to implement incremental synchronization between the source instance and the standby instance on the Tencent Cloud PostgreSQL. The master-standby synchronization progress in the task list needs to be observed in time. Once synchronization is achieved, be sure that the source instance needs to stop writing.
﻿
﻿
﻿
5. Waiting for Switch
When the difference in the master-standby incremental synchronization between the source instance and the standby instance on the Tencent Cloud PostgreSQL is 0, the system is waiting for a switch. You need to manually click Complete to initiate the switch.
﻿
﻿
﻿
6. Switching
After you click Complete, the system will switch the standby machine on the Tencent Cloud PostgreSQL to the master.
Note:
The system can execute the switch after detecting that the instant LSNs are the same on the source and target instances, but this does not means that the source instance has stopped writing. Please be sure that the source instance has ceased writing before proceeding with the switch.
7. Completion
After the switch, the standby machine acts as the master. The Tencent Cloud PostgreSQL management system will take over the new master and adapt to the corresponding management operations.
Notes
Instances must be master instances, read-only, and do not support physical migration.
Physical replication does not support data transfer to or from sources or targets with Transparent Data Encryption (TDE) enabled.
﻿

Physical Migration Check Items

Last updated：2025-04-07 17:03:14

The following describes the pre-task check items of TencentDatabase for PostgreSQL physical migration:
Database Connection Check
For detailed check information, reasons, and solutions, see Source/Target Instance Connection Check.
Version Check
The major version of both the source and target instances needs to be consistent, and the kernel version of the target instance cannot be lower than the following versions.
Major Version
Kernel Version
10
v10.17_r1.5
11
v11.12_r1.5
12
v12.7_r1.5
13
v13.3_r1.4
14
v14.2_r1.11
15
v15.1_r1.4
16
v16.0_r1.2
Source Instance Permission Check
Check Details
The account for the source instance migration needs to have LOGIN and REPLICATION permissions.
The configuration of the pg_hba.conf file of the source instance must meet system requirements.
Fix
Users may not have the operation permissions. Please grant users permissions based on the permission requirements in the check details and run the verification task again.
If an error similar to connect source with replication failed: pq: no pg_hba.conf entry for replication connection from host "xx.xx.xxx.xx", user "xxx" occurs, the configuration of the pg_hba.conf file of the source instance does not meet migration requirements. You can add host replication all 0.0.0.0/0 md5 to the pg_hba.conf file of the source instance, and then restart the instance or execute select pg_reload_conf(); to reload the configuration.
Note:
When there are permission and password conflicts between source and target instance database accounts, the system uses the source instance account configuration by default.
If the source instance is a PostgreSQL instance from another cloud provider, please use the account with the highest permissions to migrate.
Target Instance Table Existence Check
Check Details
Check if the target instance is empty.
Note:
The have user-created database account can be used on the target instance, but it cannot contain created databases or objects.
Fix
Existing databases or objects on the target instance need to be deleted.
Initial User Inspection
Inspection Details
Database objects under the user with source instance UID=10 will trigger an alarm.
Remediation Method
Change the owner of the database objects under the user with UID=10 to another client.
Target Database Space Check
Check Details
The disk space of the target instance needs to be at least larger than 110% of the disk space occupied by the source instance. Otherwise, an error will be reported.
Fix
To expand the disk space on the target end, see Modifying instance configuration.
Key Parameter Check for the Instance
Check Details
wal_level of the source instance must be logical.
block_size of the source and target instances must be the same.
For instance of PostgreSQL lower than version 13, the value of wal_keep_segments in the source instance must be greater than or equal to 256.
For PostgreSQL 13 and later versions, the value of wal_keep_size/wal_segment_size in the source instance must be greater than or equal to 256.
wal_block_size of the source and target instances must be the same.
segment_size of the source and target instances must be the same.
max_connections of the target instance must be greater than or equal to max_connections of the source instance.
max_wal_senders of the target instance must be greater than or equal to the max_wal_senders of the source.
max_worker_processes of the target instance must be greater than or equal to max_worker_processes of the source.
Fix
Modify the parameters of the source or target instance according to the requirements in the check details.
Plugin Conflict Check
Check Details
Check if the plugins installed on the source instance are supported by the target instance. If not, the system will report an error. Moreover, if the plugin versions on the source and target instances are inconsistent, the system will report a warning.
Fix
Ensure consistency of plugins between source and target instances by installing or upgrading plugin versions.
Parameter Conflict Check
Check Details
In principle, the parameter values of the source and target instances need to be consistent. When the system detects inconsistent parameter values between the source and target, the usual approach is that use the target instance's parameter values and do not notify the user. Different approaches apply to the following parameters:
Parameter Name
Default Handling for Migration
Verification Action
data_checksums
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
enable_partitionwise_aggregate
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
enable_partitionwise_join
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
lc_ctype
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
max_locks_per_transaction
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
max_prepared_transactions
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
random_page_cost
Use the parameter value of the source instance.
There is no alert when the parameter values are different.
max_connections
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_wal_senders
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_worker_processes
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
array_nulls
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
authentication_timeout
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_analyze_scale_factor
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_analyze_threshold
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_freeze_max_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_multixact_freeze_max_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_naptime
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_cost_delay
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_cost_limit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_insert_scale_factor
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_insert_threshold
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_scale_factor
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
autovacuum_vacuum_threshold
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
bytea_output
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
check_function_bodies
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
constraint_exclusion
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
cursor_tuple_fraction
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
DateStyle
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
deadlock_timeout
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
default_statistics_target
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
default_transaction_isolation
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
exit_on_error
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
extra_float_digits
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
from_collapse_limit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_effort
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_generations
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_pool_size
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_seed
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_selection_bias
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
geqo_threshold
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
idle_in_transaction_session_timeout
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
idle_session_timeout
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
IntervalStyle
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
jit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
jit_above_cost
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
jit_inline_above_cost
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
jit_optimize_above_cost
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
join_collapse_limit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
lc_monetary
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
lc_numeric
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
lc_time
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
local_preload_libraries
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
log_filename
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_logical_replication_workers
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_parallel_workers
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_replication_slots
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_standby_archive_delay
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
max_standby_streaming_delay
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
recursive_worktable_factor
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
search_path
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
statement_timeout
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
stats_fetch_consistency
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
TimeZone
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_cost_delay
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_cost_limit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_cost_page_dirty
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_cost_page_hit
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_cost_page_miss
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_freeze_min_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_freeze_table_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_multixact_freeze_min_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
vacuum_multixact_freeze_table_age
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
wal_level
Use the parameter value of the target instance.
There is an alert for the user to modify the parameter when parameter values are different. If the parameter is not modified, the default handling method for the migration will be adopted.
Fix
Modify the parameter values as needed.
Target Instance Status Check
Check Details
TDE data encryption cannot be enabled for the target instance
In the target instance, read-only groups are allowed, but associated read-only instances are not allowed.
No user connections are allowed for the target instance.
Note:
During physical migration, ensure that the source instance is not an encrypted instance.
Fix
Currently, TDE instances and read-only instances are not supported.
Glibc Version Compatibility Check
Check Details
Check the glibc version compatibility issue between the source instance and target instance.
Note:
The sorting rules for some UTF8 characters of glibc 2.28 have been changed. When versions are incompatible, the data sorting rules are different, resulting in a risk of unexpected sorting results.
Fix
Upgrade the glibc version.

DTS-Based Data Sync

Usage Instructions

Last updated：2025-06-06 15:01:40

Category
Description
Supported Versions
1. Source database
Self-built database PostgreSQL 10-16
Third-party cloud vendors (Alibaba Cloud RDS PostgreSQL/AWS RDS PostgreSQL/Huawei Cloud RDS for PostgreSQL) 10-16
TencentDB for PostgreSQL 10-16 (Migration between same master accounts / Migration between different main accounts)
2. Target database
TencentDB for PostgreSQL 10-16
Source database impact
1. DTS occupies certain source instance resources when executing full data synchronization, which may lead to an increase in the load of the source instance and add pressure on the database itself. If your database configuration is too low, it is recommended that you perform operations during business off-peak hours. 
2. Defaults to a lock-free method. No global lock is applied to the source database during the sync process. 
3. When performing data synchronization, DTS uses the account executing the synchronization task to create postgres.public.identify and {database}.__tencentdb__sync_*.* in the source database to record task status and configuration information. The target instance uses the {database}.__tencentdb__ schema to record synchronization status information. postgres.public.identify, {database}.__tencentdb__sync_*.*, and {database}.__tencentdb__ schema occupy very little space, about one-thousandth to one-ten-thousandth of the source database storage space. Therefore, they have no impact on the performance of the source database and do not preempt resources.
4. The sync task depends on the max_replication_slots parameter (one replication_slot is occupied when configuring a sync task for each database). You can view the usage status by using the SQL statement "select * from pg_replication_slots". If the number of configured sync databases + replication_slots > max_replication_slots, creating a new sync task will fail. Users are advised to end the task proactively before the system releases the replication_slots (replication_slots will not be released if the failed task is not ended).
sync object
1. Unsupported object synchronization: ROLE, PROCEDURE, TRIGGER, FUNCTION, RULE.
2. No support for synchronization of public objects and permission changes.
3. Foreign key import is not supported during structure initialization in the full-load phase. Foreign key constraints will be automatically removed before import.
4. Data sync does not support the FOREIGN TABLE table type. Export and import do not support TEMPORARY TABLE in the full-load phase. Only UNLOGGED TABLE data structure sync is supported in the incremental synchronization phase.
5. The source database updates SEQUENCE objects in the incremental phase. After synchronization to the target database, refreshing the last_value of the SEQUENCE is not supported. Users may need to manually check the sync result and modify the parameter value on the target database.
6. After the objects in the source database are synchronized to the target end, the object owner will be changed to the target database account. For example, if the owner of table 1 was A before, and account B is used for synchronization in the target database, the owner of table 1 will be changed to B after being written into the target database.
7. Cannot select the entire source instance for synchronization. If there is an operation to create a new database (CREATE DATABASE) on the source side in subsequent synchronization tasks, it is recommended to create the repository object on the target side before starting the synchronization task.
8. If there are CREATE TABLE or RENAME TABLE operations on the source during the sync task process, please select the entire database where the table is located when selecting the sync object in the configuration phase. Otherwise, the newly created table or the renamed table will not be synchronized to the target end.
Data Type
1. Data types supported
Aclitem,Bit,Bool,Box,Bpchar,Bytea,Char,Cid,Cidr,Circle,Date,Float4,Float8,Inet,Int2,Int4,Int8,Interval,Json,Jsonb,Jsonpath,Line,Lseg,Macaddr,Name,Numeric,Oid,Path,Point,Polygon,Record,Text,Tid,Time,Timestamp,Timestamptz,Unknown,Uuid,Varbit,Varchar,XID,Daterange,Int4range,Int8range,Numrange,Tsrange,Tstzrange,Datemultirange,Int4multirange,Int8multirange,Nummultirange,
Tsmultirange,Tstzmultirange,XML,Money,Time with time zone,Tsvector,Tsquery,pg_lsn,txid_snapshot.
2. Time zone
Fields with time zone (timestamp with time zone) in the source instance will automatically convert to the corresponding value of the target instance time zone after synchronizing to the target instance.
Supported SQL
1. DML
INSERT,UPDATE,DELETE
2. DDL
DROP DATABASE,ALTER DATABASE
CREATE SCHEMA,DROP SCHEMA
CREATE TABLE,ALTER TABLE,DROP TABLE
CREATE VIEW,DROP VIEW
CREATE INDEX,DROP INDEX
CREATE SEQUENCE,DROP SEQUENCE
Note:
CREATE TABLE table name AS SELECT statement is not currently supported.
SQL Filter Policy with Where condition filtering is not currently supported.
Limits of Operation
Do not perform the following operations during the sync process, otherwise the synchronization task will fail.
1. Do not modify or delete user information (including username, password and permissions) and port number in the source database and target database.
2. During the incremental synchronization phase, concurrent DDL and DML operations may cause data conflicts. It is recommended to reduce DDL during the incremental phase.
3. Do not perform the operation of purging WAL on the source database.
4. Do not delete the system database and schema postgres.public.identify, __tencentdb__sync_*.*, {database}.__tencentdb__ schema during the synchronous increment stage.
5. When the source and target database types are Tencent Cloud Database, do not modify the network of the database instance. If the network of the source instance and the target instance changes, causing the original VIP to be deleted, the synchronization task to fail, or to remain running unchanged (at this point, the synchronization is no longer working), in this case, the synchronization task cannot be retried. You need to manually end the task and then reestablish a new synchronization task.
Data Synchronization Description
1. When DTS initiates a data synchronization task, it sets the REPLICA IDENTITY FULL attribute for tables awaiting synchronization and newly created tables (for tasks with incremental DDL enabled). However, if there are long-running transactions on the table, this may result in a timeout during the setup process, ultimately causing the task to fail.
2. When DTS initiates a data synchronization task, if the database instance contains uncommitted long-running transactions, the creation of the replication slot may time out, thereby leading to task failure.
Source database HA 
HA occurs in the source database and migration of the primary node of the source instance occurs, causing changes in the WAL log. The original synchronization task will fail. The synchronized data in the target database needs cleaning, and then a new synchronization task needs to be established.

Synchronization Guidance

Last updated：2025-04-30 18:29:39

Overview
This document introduces the process of synchronizing PostgreSQL data to TencentDB for PostgreSQL using Data Transfer Service (DTS).
Preparations
1. Read carefully instructions to understand feature constraints and precautions.
2. According to the access type you need to use, connect DTS and the database in advance. For details, see Network Preparation Work.
Self-hosted IDC database/database from other cloud vendors: The access methods available include "Public Network/Direct Connect/VPN Access/Cloud Connect Network".
When migrating a public network instance, please ensure that the source instance service is accessible in the public network environment, and maintain the stability of the public network connection. Fluctuations or failures in the network can cause migration failure. Once the migration fails, you need to reinitiate the migration task.
Self-built Database on CVM: Select "self-built on CVM" as the access method.
Tencent Cloud database instance: Select "CloudDB" as the access method.
3. The account that executes the DTS synchronization task must have the permissions of the source database: Event Trigger, Replication, CREATE, DROP, ALTER, SELECT, UPDATE, INSERT, DELETE.
4. The account that executes the DTS synchronization task must have the permissions of the target database: CREATE, DROP, ALTER, SELECT, UPDATE, INSERT, DELETE.
Operation Steps
1. Log in to data synchronization purchase page, select the corresponding configuration, and click Buy Now.
Parameter
Description
Billing Mode
Support annual and monthly subscription and pay-as-you-go.
Source instance type
Select PostgreSQL. It cannot be modified after purchase.
Source instance region
Select the source instance location. It cannot be modified after purchase.
Types of target instances
Select PostgreSQL. It cannot be modified after purchase.
Target instance region
Select the target instance location. It cannot be modified after purchase.
Specification
Select specifications according to business requirements. The higher the specifications, the better the performance. For details, see Billing Overview.
2. After purchase completion, return to Data Sync List. You can see the newly created data sync task. The newly created sync task needs to be configured before use.
3. In the data synchronization list, click Configure in the Operation column to enter the synchronization task configuration page.
﻿
4. On the synchronization task configuration page, configure the source instance, account and password, configure the target instance, account and password. After testing connectivity, click Next.
﻿
Due to the considerable intersect scenarios between the source database deployment form and access type, the sync operation steps in each scenario are similar. The following only provides configuration examples of typical scenarios. For other scenarios, users can refer to the configuration.
Example one: Synchronize the locally self-built database to the tencent cloud database via dedicated line/VPN.
Settings
Parameter
Description
Task Settings
Task Name
DTS will automatically generate a task name. Users can set it according to the actual situation.
﻿
Running Mode
Support two modes: immediate execution and scheduled execution.
Source Instance Setting
Source instance type
The source instance type selected at the time of purchase cannot be modified.
﻿
Source instance region
The source instance location selected at the time of purchase cannot be modified.
﻿
Access type
Based on your scenario selection, this scenario chooses "Direct Connect" or "VPN Access". This scenario requires configuring interconnectivity between VPN and IDC. For preparation work of other access types, refer to Preparation Overview.
Public network: The source database can be accessed through a public IP address.
Self-built cloud host: The source database is deployed on Tencent Cloud CVM.
Dedicated line access: The source database can be connected to the Tencent Cloud private network through Dedicated Line Access.
VPN access: The source database can be connected to the Tencent Cloud private network through VPN Connections.
Cloud database: The source database belongs to a Tencent Cloud database instance.
CCN: The source database can be connected to the Tencent Cloud private network through CCN.
﻿
VPC Direct Connect gateway/VPN gateway
Direct connect only supports VPC direct connect gateway. Please confirm the gateway associated network type. For VPN gateway, please select the VPN gateway instance that accesses via VPN gateway.
﻿
Virtual Private Cloud (VPC)
Select the Virtual Private Cloud (VPC) and subnet associated with the VPC Direct Connect gateway and VPN gateway.
﻿
Host address
Source instance access IP address or domain name.
﻿
Port
Source instance access port.
﻿
Account
Source instance account and account permission should meet the requirements.
﻿
Password
The password of the source instance account.
Target instance settings
Types of target instances
The type of target instance selected when purchased cannot be modified.
﻿
Target instance region
The target instance region selected when purchased cannot be modified.
﻿
Access type
Based on your scenario selection, this scenario selects "CloudDB".
﻿
Instance ID
Select the target instance ID.
﻿
Account
Target instance account and account permission should meet the requirements.
﻿
Password
The password of the target instance account.
Example II: Synchronize the tencent cloud database to the tencent cloud database.
Settings
Parameter
Description
Task Settings
Task Name
DTS will automatically generate a task name. Users can set it according to the actual situation.
﻿
Running Mode
Support two modes: immediate execution and scheduled execution.
Source Instance Setting
Source instance type
The source instance type selected at the time of purchase cannot be modified.
﻿
Source instance region
The source instance location selected at the time of purchase cannot be modified.
﻿
Access type
For this scenario, select "TencentDB". For preparation work for different access types, refer to Preparation Overview.
Public network: The source database can be accessed through a public IP address.
Self-built cloud host: The source database is deployed on Tencent Cloud CVM.
Direct Connect: The source database can be connected to the Tencent Cloud private network through Direct Connect.
VPN access: The source database can be connected to the Tencent Cloud private network through VPN Connections.
Cloud database: The source database belongs to a Tencent Cloud database instance.
CCN: The source database can be connected to the Tencent Cloud private network through CCN.
﻿
Instance ID
The ID of the source instance.
﻿
Account
Source instance account and account permission should meet the requirements.
﻿
Password
The password of the source instance account.
Target instance settings
Types of target instances
The type of target instance selected when purchased cannot be modified.
﻿
Target instance region
The target instance region selected when purchased cannot be modified.
﻿
Access type
Based on your scenario selection, this scenario selects "CloudDB".
﻿
Instance ID
Select the target instance ID.
﻿
Account
Target instance account and account permission should meet the requirements.
﻿
Password
The password of the target instance account.
Example III: Synchronize PostgreSQL from a third-party cloud vendor to the tencent cloud database through the public network.
Settings
Parameter
Description
Task Settings
Task Name
DTS will automatically generate a task name. Users can set it according to the actual situation.
﻿
Running Mode
Support two modes: immediate execution and scheduled execution.
﻿
Automatic Retry
After configuration, if the migration task is temporarily interrupted due to network exceptions, DTS will automatically retry and recover the task within the set time. No manual intervention is required.
The configurable time range is 5 - 720 minutes.
Source Instance Setting
Source instance type
The source instance type selected at the time of purchase cannot be modified.
﻿
Source instance region
The source instance location selected at the time of purchase cannot be modified.
﻿
Access type
For third-party cloud vendor databases, you can generally choose the public network method, or choose VPN access, direct connect, or CCN. You need to choose according to the actual network conditions.
This scenario selects "public network". For preparation work for different access types, refer to Overview of Preparation Work.
Public network: The source database can be accessed through a public IP address.
Self-built cloud host: The source database is deployed on Tencent Cloud CVM.
Dedicated line access: The source database can be connected to the Tencent Cloud private network through Dedicated Line Access.
VPN access: The source database can be connected to the Tencent Cloud private network through VPN Connections.
Cloud database: The source database belongs to a Tencent Cloud database instance.
CCN: The source database can be connected to the Tencent Cloud private network through CCN.
﻿
Host address
Source instance access IP address or domain name.
﻿
Port
Source instance port.
﻿
Account
Source instance account and account permission should meet the requirements.
﻿
Password
The password of the source instance account.
Target instance settings
Types of target instances
The type of target instance selected when purchased cannot be modified.
﻿
Target instance region
The target instance region selected when purchased cannot be modified.
﻿
Access type
Based on your scenario selection, this scenario selects "CloudDB".
﻿
Instance ID
Select the target instance ID.
﻿
Account
Target instance account and account permission should meet the requirements.
﻿
Password
The password of the target instance account.
5. On the Synchronization Options and Objects page, settings can be done for data initialization options, data synchronization option, and synchronization object options. After the settings are completed, click Save and Next.
Notes:
When only full data initialization is selected for initialization type, the system, by default, assumes that the user has already created the table structure in the target database. No table structure synchronization will be performed, nor will it verify whether there are tables with the same name in the source and target databases. Therefore, when the user selects pre-validation and error reporting in existing homonymous tables at the same time, the validation and error reporting feature does not take effect.
If the user determines that a rename operation will be performed on a certain table during the sync process (for example, renaming table A to table B), then synchronization object needs to select the entire database (or entire instance) where table A resides, rather than just selecting table A. Otherwise, after the rename operation, the data of table B will not be synchronized to the target database.
﻿
Settings
Parameter
Description
Data Initialization Option
Initialization Type
Table structure initialization: During synchronous task execution, the table structure in the source instance will be initialized to the target instance first.
Full data initialization: During synchronous task execution, the data in the source instance will be initialized to the target instance first. In scenarios where only full data initialization is selected, users need to create the table structure in the target database in advance.
Both are selected by default and can be canceled based on the actual situation.
﻿
Existing homonymous table
Pre-validation and error reporting: If a table with the same name exists, an error will be reported and the process will no longer continue.
Ignore and continue execution: Add full data and incremental data directly to the table of the target instance.
Data Sync Option
Conflict Resolution Mechanism
Conflict Error: When a primary key conflict is detected during synchronization, an error will be reported and the data sync task will be suspended.
Conflict ignored: When a primary key conflict is detected during synchronization, retain the primary key record in the target database.
Conflict overwrite: When a primary key conflict is detected during synchronization, overwrite the primary key record in the target database with the primary key record in the source database.
﻿
Sync operation type
Support operations: Insert, Update, Delete, DDL. DDL customization is not supported currently.
Synchronization object options
Source instance database and table objects
Select objects to be synchronized. Basic tables and views are supported. Only SEQUENCE is supported for advanced objects.
6. On the task verification page, after completing verification and passing all verification items, click Start Task.
7.  If the validation task fails, refer to handling method for validation failure to fix issues and re-initiate the validation task.
Failure: Indicate that a check item fails, task blocking, need to fix the problem and run the verification again.
Warning: Indicate that the inspection item check is not fully compliant. The task can be continued, but it has an impact on the business. Assess based on the prompt whether to ignore the warning or fix the problem and continue.
Note:
When performing plug-in detection in the pre-verification stage, after reporting an alarm for the first mismatched plug-in, continue detection of the remaining plug-ins no longer.
﻿
8. Return to the data synchronization task list. The task starts and enters the Running status.
Note:
Select More > Finish in the Operation column to close the sync task. Please make sure data synchronization is complete before closing the task.
﻿
9. (Optional) You can click Task Name to go to task details page and view task initialization status and monitoring data.

Handling Front Validation Failure

Connecting to DB Check

Last updated：2025-04-30 17:53:50

Check Detail
The source database and target database need to have normal connectivity. If they are disconnected, a connection failure will be reported.
Causes of Issues
﻿The network or server where the source database is located has a security group or firewall configured.﻿
﻿The source database restricts the source IP address..
﻿The network port is not open..
The database account or password is incorrect.
Remediation Method
Handle according to the corresponding link of the problem cause.
﻿

Object Dependency Check

Last updated：2025-04-30 17:54:25

Check Detail
1. If "Full migration" or "Full + Incremental migration" is selected on the DTS task configuration interface, but no specific tables to be migrated are selected in the migration objects except for common objects, the validation task will report an error. Please select table objects.
2. If a view is selected as a migration object, but the table that the view depends on is not selected, the verification task will report an error. Interrelated objects need to be migrated together.
Remediation Method
Reconfigure the DTS task. Interrelated objects need to be migrated together.
﻿

Version Check

Last updated：2025-04-30 17:55:38

Check Detail
Migration scenarios
Full + incremental migration. The version numbers of both the source instance and the target instance must be greater than or equal to 10.0.
When there is a version inconsistency between the source instance and the target instance, there will be some special compatibility issues, and the task will issue a warning. Please read the compatibility reports of each version on your own to confirm whether there is use of incompatible characteristics in your business.
Synchronization scenarios
Versions earlier than PostgreSQL 10 do not support synchronization. For data synchronization, the version of the target instance must be greater than or equal to that of the source instance.
When there is a version inconsistency, there will be some special compatibility issues, and the task will issue a warning. Please read the compatibility reports of each version on your own to confirm whether there is use of incompatible characteristics in your business.
Fix
Check the source and target databases according to the version requirement. If the source database or target database version is unsupported, upgrade the target instance version or use a higher version of the database instance.

Source or Target Instance Permission Check

Last updated：2025-04-30 17:56:46

Check Detail
Check whether the user has permission to operate the database. For details, see the corresponding document below.
﻿PostgreSQL data migration﻿
﻿PostgreSQL data synchronization﻿
Remediation Method
The user may not have operation permission. Grant permissions as specified in the check requirements, and then run the verification again.

Incremental Migration Pre-Check

Last updated：2025-04-30 17:57:57

Check Detail
When the migration type is set to incremental migration, you need to check the following conditions. Otherwise, verification will fail.
The wal_level of the source database must be logical.
The parameters max_replication_slots and max_wal_senders of the source database must be greater than the total number of libraries to be migrated (reserved additional number of connections).
The persistence attribute of tables to be migrated in the source database must be p (permanent table). Otherwise, replication is not supported, and logical migration cannot be done.
unlogged tables cannot exist in tables to be migrated. Otherwise, they cannot be migrated.
Migrate tables with a primary key. Otherwise, inconsistent data results may occur. It is not recommended that users migrate tables without a primary key.
If the table to be migrated has no primary key and no copyable flag (i.e., the REPLICA IDENTITY attribute is set to NOTHING), the validation task will raise an alarm.
If the table to be migrated has no primary key and contains field types (json/point/polygon/txid_snapshot/xml) that cannot use the = operator, the verification will fail. You need to repair the table without a primary key according to the prompt or uncheck the primary key table. Otherwise, you cannot continue the task.
Remediation Method
Modifying wal_level/max_replication_slots/max_wal_senders Parameters
Follow these steps to modify parameters wal_level, max_replication_slots, and max_wal_senders.
1. Log in to the source database.
Note:
If the source database is a self-built database, you need to log in to the running server of the database and enter the main data directory of the database, which is generally $PGDATA.
If the source database is another CloudDB, please use the parameter modification method of the relevant cloud platform.
If modifications are needed for the parameters of the target instance, please handle it through online support.
2. Normally enter the postgresql.conf file, open this file, and modify the corresponding parameter.
wal_level = logical
max_replication_slots = 10  //Change according to actual conditions
max_wal_senders = 10  //Change according to actual conditions
3. After modification, restart the database instance.
4. Log in to the database instance and use the following command to check whether the parameter values are set correctly:
postgres=> select name,setting from pg_settings where name='wal_level';
name    | setting 
-----------+---------
 wal_level | logical
(1 row)
postgres=> select name,setting from pg_settings where name='max_replication_slots';
      name          | setting 
-----------------------+---------
 max_replication_slots | 10
(1 row)
postgres=> select name,setting from pg_settings where name='max_wal_senders';
   name       | setting 
-----------------+---------
 max_wal_senders | 10
(1 row)
5. Re-run the verification task.
Modifying REPLICA IDENTITY Attribute of Table to Be Migrated
Generally, it is not recommended to migrate tables without a primary key, which may result in inconsistent data. If the table to be migrated has no primary key and does not contain a copyable identification (i.e., the REPLICA IDENTITY attribute is set to NOTHING), the validation task will raise an alarm.
A warning has occurred. It is recommended that users refer to the following method to modify the attribute parameters of the table.
ALTER TABLE schemaName.tableName REPLICA IDENTITY FULL;
﻿

Structural Compatibility Check

Last updated：2025-04-30 17:58:55

Check Detail
If the target database version is 12 or higher, and the table to be migrated contains data types abstime, reltime and tinterval, the verification task will report an error.
<data types abstime, reltime and tinterval are some older date and time types which have been deprecated in new PostgreSQL Versions. It is recommend using following types as alternatives:
abstime: Can be substituted with timestamp or timestamp with time zone types. These types provide a broader range of date and time representation capabilities.
reltime: Can be substituted with interval type. interval type is used to represent time intervals and can include units such as year, month, day, hour, minute, and second.
tinterval: Can be substituted with tsrange or tstzrange types. These types are used to represent time ranges and can include start time and end time.
Remediation Method
The modification methods for the three data types abstime, reltime and tinterval are similar. First, create a new column. Convert the old data format to the new data format and store it in the new column. After verifying that the data in the new column is correct, delete the old column. Finally, rename the new column to the name of the old column as needed.
The following takes modifying abstime to timestamp as an example for introduction.
1. In the table where the verification task prompts an error, add a new timestamp column.
ALTER TABLE your_table ADD COLUMN new_column TIMESTAMP;
2. Convert the data in the abstime column to the timestamp type and store the result in a new column.
UPDATE your_table SET new_column = your_abstime_column::TIMESTAMP;
3. Verify if data in the new column is correct.
SELECT * FROM your_table;
4. If you confirm that the data in the new column is correct, you can delete the old abstime column.
ALTER TABLE your_table DROP COLUMN your_abstime_column;
5. If necessary, you can rename the new column to the name of the old column.
ALTER TABLE your_table RENAME COLUMN new_column TO your_abstime_column;

Structure Conflict Checking

Last updated：2025-04-30 18:00:05

Check
In PostgreSQL migration scenarios, the target instance cannot have objects with the same name as those in the source database.
The target has tables, views with the same name as the migration objects. Task error.
The target has functions, triggers, indexes with the same name as the migration objects. The task triggers an alarm.
When the entire PostgreSQL instance is migrated, the target instance must be empty.
Remediation Method
If a conflict is detected, delete the conflicting content or rename the conflicting objects, and then re-verify.

Account Conflict Check

Last updated：2025-04-30 18:01:00

Check Detail
Check whether the users in the target database are duplicates of the users in the source database in migration scenarios.
Remediation Method
In the scenario of full instance migration, if an account identical to that in the source instance exists in the target instance, it is necessary to delete the account with the same name in the target instance.
If the account in the target database is an initialized account, please use the initialized account to log in to the database and execute the following statements:
create user new user with password 'password';
grant pg_tencentdb_superuser to new username;
alter user new user with CREATEDB;
alter user new user with CREATEROLE;
If the account in the target database is a user addition, use the newly created user to log in to the database and delete the conflicting user.
drop user conflicting user;
# If the conflicting user has resource dependencies, please first modify the owner of the dependent object. For example, the modification statement for the owner of a table is:
alter table table name owner to new user;
Once the conflicting user deletion is completed, please re-run the verification task.

Parameter Configuration Conflict Check

Last updated：2025-04-30 18:02:04

Check Detail
1. Check the following parameter values of the source and target databases. If there is a difference in parameter values between the source and target databases, a verification warning will be prompted. The warning will not block the migration task, but it will have an impact on the business. Please assess and decide whether to modify by yourself.
2. TimeZone,lc_monetary,lc_numeric,array_nulls,server_encoding,DateStyle,extra_float_digits ,gin_fuzzy_search_limit,xmlbinary,constraint_exclusion.
The parameter is not set consistently. The specific impact is as follows.
TimeZone: Setting the time zone of an instance. If this parameter value is inconsistent, it may lead to data errors after migration.
lc_monetary: Setting the currency mode of an instance. If this parameter value is inconsistent, it may lead to incorrect currency numbers after migration.
lc_numeric: Setting the digital mode of an instance. If this parameter value is inconsistent, it may lead to data errors after migration.
array_nulls: Setting whether the array allows empty values. If this parameter value is inconsistent, it may lead to data inconsistency after migration, and some data may fail to migrate.
server_encoding: Setting the character set of an instance. If this parameter value is inconsistent, it may lead to garbled characters in data storage.
DateStyle: Setting the date display format. If this parameter value is inconsistent, it may fail to migrate data.
extra_float_digits: Setting the output precision of floating-point values. If this parameter value is inconsistent, it will affect data accuracy. In high-precision database usage scenarios, it can cause data inconsistency after migration.
gin_fuzzy_search_limit: Set the soft upper limit of the set size returned by the GIN index. If this parameter value is inconsistent, it can cause inconsistent data display results after migration.
xmlbinary: Setting the result issue of XML function transformation. If this parameter value is inconsistent, it may lead to inconsistent behavior when executing the corresponding function in the target database compared to the source database.
constraint_exclusion: Setting whether constraints take effect. If this parameter value is inconsistent, it may lead to data inconsistency after migration.
3. Check whether the character set settings of the source and target databases are inconsistent. If they are inconsistent, errors will be reported during the validation task. Change to the same setting.
Remediation Method
1. Log in to the source database using a superuser account.
2. Execute the following example statements to modify corresponding parameters:
Users can first select the parameter modification of the source database. If the corresponding parameter of the source database cannot be modified, then the corresponding parameter of the target database needs to be modified. For the modification of the target database, please seek online support.
The server_encoding parameter cannot be modified in the source database. If this parameter is abnormal, please check whether it has been created in the target database. If it has been created and is inconsistent with the source database, you need to apply for a new instance. If it has not been created, please refer to the following methods for modification (currently, the cloud database instance only supports two character sets: UTF8 and LATIN).
alter system set timezone='<parameter value>';
alter system set lc_monetary='<parameter value>';
alter system set lc_numeric='<parameter value>';

Plug-In Compatibility Check

Last updated：2025-04-30 18:03:01

Check Detail
Check whether the plug-ins that already exist in the source database also exist in the target database.
If there is a plug-in migration on the source side and no permission to create a plug-in on the target side, a verification task error will occur.
If there is a plug-in migration on the source side and the corresponding plug-in is not installed on the target side, or the version numbers are different, a verification task error will occur.
Remediation Method
Install the same plugin version in the target database as that in the source database. At the same time, grant the corresponding permissions of the plug-in in the target database. For details, see PostgreSQL Official Guidance.
﻿

Primary Key Dependency Check

Last updated：2025-04-30 18:03:56

Check Detail
PostgreSQL sync scenario, check whether there is a primary key in the table to be synchronized. If there is no primary key, task verification will trigger an alarm, and ALTER TABLE XXX REPLICA IDENTITY will be automatically configured.
Remediation Method
According to the UI reminders, set the primary key and then run the verification again.

Critical Parameter Check for Instances

Last updated：2025-04-30 18:04:56

Check Detail
PostgreSQL sync scenario will check whether the copy parameter wal_level is equal to logical, and at the same time, replication_slots need to meet the number of databases for sync + replication_slots <= max_wal_senders.
Remediation Method
Set the instance parameter wal_level to logical.
Reduce the number of databases to be synchronized.

Multitask Conflict Detection

Last updated：2025-04-30 18:06:25

Check Detail
If there is a long-running transaction in the source database, the validation task will raise an alarm. Users can ignore the warning and continue with the task, but it is recommended that long transactions be handled before initiating the DTS task.
Remediation Method
Handle long transactions in the source database and initiate the DTS task after the end of transaction.

Long transaction check

Last updated：2025-04-30 18:07:16

Check Detail
If there is a long-running transaction in the source database, the validation task will raise an alarm. Users can ignore the warning and continue with the task, but it is recommended that long transactions be handled before initiating the DTS task.
Remediation Method
Handle long transactions in the source database and initiate the DTS task after the end of transaction.

Extension Management

Extension Overview

Last updated：2024-01-24 11:16:51

This document describes the extensions supported by TencentDB for PostgreSQL.
Extension Overview
TencentDB for PostgreSQL supports multiple open-source and proprietary extensions. They help you perform instance OPS easier and improve the query and write performance as well as various capabilities such as token query, data retrieval, and incremental data migration.
Using Extension
Currently, TencentDB for PostgreSQL supports most common extensions for direct use. However, to enable certain extensions, you need to use specified versions or get special permissions. In this case, submit a ticket and provide the instance ID and extension name to enable it.
Creating Extension
When creating an extension, the pg_tencentdb_superuser is temporarily escalated to superuser and passes all permission checks.
TencentDB for PostgreSQL extensions are managed at the database level. You can create different extensions for different databases, but databases cannot use extensions in other databases.
To create an extension, access the database with the client tool and run the following statements:
CREATE EXTENSION [ IF NOT EXISTS ] extension_name
[ WITH ]
[ SCHEMA schema_name ]
[ VERSION version ]
[ FROM old_version ]
Viewing Created Extension
If you have installed extensions, you can run the following command to view the list of extensions installed in the current database:
You can run the \dx command if you use the psql client.
\dx
                                        List of installed extensions
     Name      | Version |   Schema   |                             Description                             
---------------+---------+------------+---------------------------------------------------------------------
 amcheck       | 1.2     | public     | functions for verifying relation integrity
 bloom         | 1.0     | public     | bloom access method - signature file based index
 hstore        | 1.6     | public     | data type for storing sets of (key, value) pairs
 hstore_plperl | 1.0     | public     | transform between hstore and plperl
 jsonb_plperl  | 1.0     | public     | transform between jsonb and plperl
 plperl        | 1.0     | pg_catalog | PL/Perl procedural language
 plpgsql       | 1.0     | pg_catalog | PL/pgSQL procedural language
 postgis       | 3.0.2   | public     | PostGIS geometry, geography, and raster spatial types and functions
(8 rows)
If you want to use SQL statements to view the extensions, run the select * from pg_available_extensions where installed_version is not null; statement to view the list of installed extensions.
        name      | default_version | installed_version |                               comment                               
---------------+-----------------+-------------------+---------------------------------------------------------------------
 plperl        | 1.0             | 1.0               | PL/Perl procedural language
 amcheck       | 1.2             | 1.2               | functions for verifying relation integrity
 hstore_plperl | 1.0             | 1.0               | transform between hstore and plperl
 plpgsql       | 1.0             | 1.0               | PL/pgSQL procedural language
 jsonb_plperl  | 1.0             | 1.0               | transform between jsonb and plperl
 hstore        | 1.6             | 1.6               | data type for storing sets of (key, value) pairs
 bloom         | 1.0             | 1.0               | bloom access method - signature file based index
 postgis       | 3.0.2           | 3.0.2             | PostGIS geometry, geography, and raster spatial types and functions
(8 rows)
List of Supported Extensions
TencentDB for PostgreSQL supports multiple powerful and high-performance extensions. For the list of extensions supported by each database version, see Supported Extensions.

Instructions About Plugin Limitations on Creating

Last updated：2025-12-19 17:39:23

Instances with lower kernel versions may pose security risks when certain plugins are created. To standardize plugin management and enhance security protection, some plugins cannot be created in specific kernel versions of newly created TencentDB for PostgreSQL instances. The usage of already created plugins remains unaffected.
Note:
From December 18, 2025, if you need to use these plugins, please submit a ticket to contact us to enable them.
Plugins Scope
Range of Kernel Version
list of risk plugins
less than or equal to v10.23_r1.24
plv8,plls,plcoffee,pg_cron,age
less than or equal to v11.22_r1.30
plv8,plls,plcoffee,pg_cron,age
less than or equal to v12.22_r1.33
plv8,plls,plcoffee,pg_cron,age
less than or equal to v13.22_r1.28
plv8,plls,plcoffee,pg_cron,age
less than or equal to v14.19_r1.37
plv8,plls,plcoffee,pg_cron,age
less than or equal to v15.14_r1.22
plv8,plls,plcoffee,pg_cron,age
less than or equal to v16.10_r1.17
plv8,plls,plcoffee,pg_cron,age
less than or equal to v17.6_r1.11
plv8,plls,plcoffee,pg_cron,age
less than or equal to v18.0_r1.1
plv8,plls,plcoffee,pg_cron,age

Supported Extensions

Overview

Last updated：2025-12-11 14:24:47

TencentDB for PostgreSQL now supports creating custom extensions (CREATE EXTENSION <extension name>). This document describes the extensions and their versions supported by different kernel major versions of TencentDB for PostgreSQL.
Plugin Name    
v10
v11
v12
v13
v14
v15
v16
v17 
v18
address_standardizer
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
address_standardizer_data_us 
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
age
-
-
-
5.0
5.0
5.0
5.0
5.0
5.0
auth_delay 
0 
0 
0 
0 
0 
0 
0 
0 
0 
auto_explain 
0 
0 
0 
0 
0 
0 
0 
0 
0 
autoinc      
0 
0 
0 
0 
0 
0 
0 
0 
0 
bloom
0 
0 
0 
0 
0 
0 
0 
0 
0 
bool_plperl  
   -
-
-
0 
0 
0 
0 
0 
0 
btree_gin     
2
3
3
3
3
3
3
3
3
btree_gist    
5
5
5
5
6
7
7
7
7
chkpass        
0 
0 
0 
0 
0 
0 
0 
0 
0 
citext
4 
5 
6 
6 
6 
6 
6 
6 
6 
cos_fdw
0 
0 
0 
0 
0 
0 
0 
0 
0 
count_distinct
-
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
cube
2 
4 
4 
4 
5 
5 
5 
5 
5 
dblink
2 
2 
2 
2 
2 
2 
2 
2 
2 
decoder_raw   
0 
0 
0 
0 
0 
0 
0 
0 
0 
decoderbufs   
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
dict_int          
0 
0 
0 
0 
0 
0 
0 
0 
0 
dict_xsyn      
0 
0 
0 
0 
0 
0 
0 
0 
0 
earthdistance
1
1
1
1
1
1
1
1
1
fuzzystrmatch
1
1
1
1
1
1
2
2
2
hll  
14
14
14
15
16
16
18
18
18
hstore             
4
5
6
7
8
8
8
8
8
hstore_plperl
0 
0 
0 
0 
0 
0 
0 
0 
0 
hypopg
-
4.1
4.1
4.1
4.1
4.1
4.1
4.1
4.1
imgsmlr          
0 
0 
0 
0 
0 
0 
0 
0 
0 
insert_username  
0 
0 
0 
0 
0 
0 
0 
0 
0 
intarray           
2
2
2
3
5
5
5
5
5
isn                 
1
2
2
2
2
2
2
2
2
jsonb_plperl    
-
0 
0 
0 
0 
0 
0 
0 
0 
lo
1 
1 
1 
1 
1 
1 
1 
1 
1 
ltree
1 
1 
1 
2 
2 
2 
2 
3 
3 
moddatetime   
0 
0 
0 
0 
0 
0 
0 
0 
0 
mysql_fdw      
0 
0 
1 
1 
1 
1 
2 
2 
2 
old_snapshot
-
-
-
-
0 
0 
0 
-
-
orafce            
-
-
8
-
15
-
-
-
-
pg_bigm  
2
2
2
2
2
2
2
2
2 
pg_buffercache
3
3
3
3
3
3
4
5
5
pg_freespacemap
2
2
2
2
2
2
2
2
2 
pg_hashids  
2.1
2.1
2.1
2.1
3
3
3
3
3
pg_hint_plan  
3.6
3.6
3.6
3.7
4.1
4.1
6.0
7.0
7.0
pg_ivm
-
-
-
11
11
11
11
11
11
pg_jieba         
-
1.1
1.1
1.1
1.1
1.1
1.1
1.1
1.1
pg_partman
-
7.3 
7.4
7.4
7.4
7.4
7.4
7.4
7.4
pg_pathman   
-
5
5
5
-
-
-
-
-
pg_prewarm   
1
2
2
2
2
2
2
2
2
pg_repack 
4.4
5.2
5.2
5.2
5.2
5.2
5.2
5.2
5.2
pg_similarity
-
0 
0 
0 
0 
0 
0 
0 
0 
pg_sphere
-
5.1
5.1
5.1
5.1
5.1
5.1
5.1
5.1
pg_stat_log
0 
0 
0 
0 
0 
0 
0 
0 
0 
pg_stat_statements
6
6
7
8
9
10
10
11
11
pg_trgm 
3 
4 
4 
5 
6 
6 
6 
6 
6 
pgagent
4
4
4
2.3
2.3
2.3
2.3
2.3
2.3
pgcrypto        
3
3
3
3
3
3
3
3
3
pglogical            
-
4.4
4.4
4.4
4.4
4.4
4.4
4.5
4.5
pgrouting    
2.2
2.2
2.2
2.2
2.2
2.2
5.1
6.2
6.2
pgrowlocks 
2
2
2
2
2
2
2
2
2
pgstattuple        
5
5
5
5
5
5
5
5
5
pipelinedb
0.0
0.0
-
-
-
-
-
-
-
pldbgapi  
-
1
1
1
1
1
1
1
1
plperl                 
0 
0 
0 
0 
0 
0 
0 
0 
0 
plpgsql               
0 
0 
0 
0 
0 
0 
0 
0 
0 
postgis        
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
postgis_raster
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
postgis_sfcgal   
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
postgis_tiger_geocoder
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
postgis_topology      
0.1
0.1
0.2
0.2
2.1
3.2
4.0
5.0
5.0
postgres_fdw     
0 
0 
0 
0 
1
1
1
1
1
rdkit
8
8
8
8
0.1
0.1
0.1
5.0
5.0
rds_server_handler
0 
0 
0 
0 
0 
0 
0 
0 
0 
refint  
0 
0 
0 
0 
0 
0 
0 
0 
0 
roaringbitmap
5
5
5
5
5
5
5
5
5
rum   
3
3
3
3
3
3
3
3
3
seg      
1
3
3
3
4
4
4
4
4
sequential_uuids
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
smlar        
-
0 
0 
0 
0 
0 
0 
0 
0 
sslinfo 
2
2
2
2
2
2
2
2
2
starrocks_fdw
-
-
-
0
0
0
0
0
0 
tablefunc
0 
0 
0 
0 
0 
0 
0 
0 
0 
tcn        
0 
0 
0 
0 
0 
0 
0 
0 
0 
tencentdb_ai
-
-
-
-
-
-
-
1
1
tencentdb_failover_slot
0 
0 
0 
0 
0 
0 
0 
-
-
tencentdb_pwdcheck
0 
0 
0 
0 
0 
0 
0 
0 
0 
tencentdb_sql_throttling
-
-
-
-
0 
0 
0 
0 
0 
tencentdb_stat  
0 
0 
0 
0 
0 
-
-
-
-
tencentdb_superuser
0 
0 
0 
0 
0 
0 
0 
0 
0 
tencentdb_system_stat
-
0 
0 
0 
0 
0 
0 
0 
0 
timetravel       
0
0
-
-
-
-
-
-
-
timescaledb
7.5
7.5
6.0
9.1
9.1
9.1
13.0
17.1
17.1
topn 
4.0
4.0
4.0
4.0
4.0
4.0
6.0
6.0
6.0
tsm_system_rows
0 
0 
0 
0 
0 
0 
0 
0 
0 
tsm_system_time
0 
0 
0 
0 
0 
0 
0 
0 
0 
unaccent
1
1
1
1
1
1
1
1
1
uuid-ossp  
1
1
1
1
1
1
1
1
1
vector    
-
-
8.0
8.0
8.0
8.0
8.0
8.0
8.0
wal2json
3
3
3
3
3
3
5
6
6
xml2     
1
1
1
1
1
1
1
1
1
zhparser            
0 
0 
2 
0 
2 
2 
2
2
2

TencentDB for PostgreSQL 9.3

Last updated：2024-01-24 11:16:51

This document lists the extensions supported by different kernel versions of TencentDB for PostgreSQL 9.3.
Extension
v9.3.25_r1.3
v9.3.25_r1.2
v9.3.25_r1.1
v9.3.5_r1.0
pg_hint_plan
1.1.4
1.1.4
1.1.4
1.1.4
pg_prewarm
Unsupported
Unsupported
Unsupported
Unsupported
pg_stat_error
1
1
1
1
pg_stat_log
1
1
1
1
pg_stat_statements
1.1
1.1
1.1
1.1
pgrowlocks
1.1
1.1
1.1
1.1
sslinfo
1
1
1
1
tablefunc
1
1
1
1
tcn
1
1
1
1
unaccent
1
1
1
1
uuid-ossp
1
1
1
1
pg_cron
Unsupported
Unsupported
Unsupported
Unsupported
pgagent
4
4
4
4
pg_partman
Unsupported
Unsupported
Unsupported
Unsupported
tsearch2
1
1
1
1
postgis
2.3.0
2.3.0
2.3.0
2.3.0
postgis_raster
Unsupported
Unsupported
Unsupported
Unsupported
postgis_sfcgal
2.3.0
2.3.0
2.3.0
Unsupported
postgis_tiger_geocoder
2.3.0
2.3.0
2.3.0
2.3.0
postgis_topology
2.3.0
2.3.0
2.3.0
2.3.0
pgrouting
2.4.1
2.4.1
2.4.1
2.4.1
address_standardizer
2.3.0
2.3.0
2.3.0
2.3.0
address_standardizer_data_us
2.3.0
2.3.0
2.3.0
2.3.0
earthdistance
1
1
1
1
plperl
1
1
1
1
plpgsql
1
1
1
1
pltcl
1
1
1
1
plv8
2.0.0
2.0.0
2.0.0
2.0.0
bool_plperl
Unsupported
Unsupported
Unsupported
Unsupported
jsonb_plperl
Unsupported
Unsupported
Unsupported
Unsupported
hstore
1.2
1.2
1.2
1.2
hstore_plperl
Unsupported
Unsupported
Unsupported
Unsupported
plcoffee
2.0.0
2.0.0
2.0.0
2.0.0
plls
2.0.0
2.0.0
2.0.0
2.0.0
timescaledb
Unsupported
Unsupported
Unsupported
Unsupported
pipelinedb
Unsupported
Unsupported
Unsupported
Unsupported
rdkit
Unsupported
Unsupported
Unsupported
Unsupported
imgsmlr
1
1
1
1
zhparser
1
1
1
1
intagg
1
1
1
1
intarray
1
1
1
1
isn
1
1
1
1
xml2
1
1
1
1
jsonbx
Unsupported
Unsupported
Unsupported
Unsupported
dict_int
1
1
1
1
dict_xsyn
1
1
1
1
citext
1
1
1
1
ltree
1
1
1
1
postgres_fdw
1
1
1
1
orafce
3.3
3.3
3.3
3.3
chkpass
1
1
1
1
bloom
Unsupported
Unsupported
Unsupported
Unsupported
btree_gin
1
1
1
1
btree_gist
1
1
1
1
roaringbitmap
Unsupported
Unsupported
Unsupported
Unsupported
rum
Unsupported
Unsupported
Unsupported
Unsupported
cube
1
1
1
1
decoderbufs
Unsupported
Unsupported
Unsupported
Unsupported
pg_bigm
Unsupported
Unsupported
Unsupported
Unsupported
fuzzystrmatch
1
1
1
1
hll
Unsupported
Unsupported
Unsupported
Unsupported
pg_trgm
1.1
1.1
1.1
1.1
pg_hashids
1.2.1
1.2.1
1.2.1
1.2.1
pgcrypto
1
1
1
1
cos_fdw
Unsupported
Unsupported
Unsupported
Unsupported
topn
Unsupported
Unsupported
Unsupported
Unsupported
﻿

TencentDB for PostgreSQL 9.5

Last updated：2024-01-24 11:16:51

This document lists the extensions supported by different kernel versions of TencentDB for PostgreSQL 9.5.
Extension
v9.5.25_r1.3
v9.5.25_r1.2
v9.5.25_r1.1
v9.5.4_r1.0
pg_hint_plan
1.1.5
1.1.5
1.1.5
1.1.5
pg_prewarm
1
1
1
Unsupported
pg_stat_error
1
1
1
1
pg_stat_log
1
1
1
1
pg_stat_statements
1.3
1.3
1.3
1.3
pgrowlocks
1.1
1.1
1.1
1.1
sslinfo
1
1
1
1
tablefunc
1
1
1
1
tcn
1
1
1
1
unaccent
1
1
1
1
uuid-ossp
1
1
1
1
pg_cron
1.1
1.1
1.1
1.1
pgagent
1.2
1.2
1.2
4
pg_partman
2.6.4, 1.4
2.6.4, 1.4
2.6.4, 1.4
2.6.4, 1.4, 1.0
tsearch2
1
1
1
1
postgis
2.3.0
2.3.0
2.3.0
2.3.0
postgis_raster
Unsupported
Unsupported
Unsupported
Unsupported
postgis_sfcgal
2.3.0
2.3.0
2.3.0
Unsupported
postgis_tiger_geocoder
2.3.0
2.3.0
2.3.0
2.3.0
postgis_topology
2.3.0
2.3.0
2.3.0
2.3.0
pgrouting
2.4.1
2.4.1
2.4.1
2.4.1
address_standardizer
2.3.0
2.3.0
2.3.0
2.3.0
address_standardizer_data_us
2.3.0
2.3.0
2.3.0
2.3.0
earthdistance
1
1
1
1
plperl
1
1
1
1
plpgsql
1
1
1
1
pltcl
1
1
1
1
plv8
2.0.0
2.0.0
2.0.0
2.0.0
bool_plperl
Unsupported
Unsupported
Unsupported
Unsupported
jsonb_plperl
Unsupported
Unsupported
Unsupported
Unsupported
hstore
1.3
1.3
1.3
1.3
hstore_plperl
1
1
1
1
plcoffee
2.0.0
2.0.0
2.0.0
2.0.0
plls
2.0.0
2.0.0
2.0.0
2.0.0
timescaledb
Unsupported
Unsupported
Unsupported
Unsupported
pipelinedb
Unsupported
Unsupported
Unsupported
Unsupported
rdkit
Unsupported
Unsupported
Unsupported
Unsupported
imgsmlr
1
1
1
1
zhparser
1
1
1
1
intagg
1
1
1
1
intarray
1
1
1
1
isn
1
1
1
1
xml2
1
1
1
1
jsonbx
1
1
1
1
dict_int
1
1
1
1
dict_xsyn
1
1
1
1
citext
1.1
1.1
1.1
1.1
ltree
1
1
1
1
postgres_fdw
1
1
1
1
orafce
3.3
3.3
3.3
3.3
chkpass
1
1
1
1
bloom
Unsupported
Unsupported
Unsupported
Unsupported
btree_gin
1
1
1
1
btree_gist
1.1
1.1
1.1
1.1
roaringbitmap
Unsupported
Unsupported
Unsupported
Unsupported
rum
Unsupported
Unsupported
Unsupported
Unsupported
cube
1
1
1
1
decoderbufs
Unsupported
Unsupported
Unsupported
Unsupported
pg_bigm
1.2
1.2
1.2
1.2
fuzzystrmatch
1
1
1
1
hll
2.14
2.14
2.14
2.14
pg_trgm
1.1
1.1
1.1
1.1
pg_hashids
1.2.1
1.2.1
1.2.1
1.2.1
pgcrypto
1.2
1.2
1.2
1.2
cos_fdw
Unsupported
Unsupported
Unsupported
Unsupported
topn
Unsupported
Unsupported
Unsupported
Unsupported
﻿

Creating a Plugin in TencentDB for PostgreSQL Instance

Last updated：2025-08-14 17:04:48

This document describes how to create a plugin in a TencentDB for PostgreSQL instance.
Prerequisites
The TencentDB for PostgreSQL instance has been created. For specific steps, see Creating TencentDB for PostgreSQL Instance.
Operation Steps
Querying Plugin Support and Supported Versions
Method One: Query Document
The supported plugins and versions vary across different major versions of instances. You can query them in the Overview.
Method Two: Database Query
Log in to the TencentDB for PostgreSQL console and execute the following statement to query supported versions of plugins. This example uses a database instance of major version 17 to create a vector plug-in.
SELECT * FROM pg_available_extensions WHERE name = 'vector';
The returned results are as follows. Among them, the default_version column shows the plugin versions supported for installation. The vector plugin supports version 0.8.0.
﻿
2. Modify Parameters (Optional)
Creating some plug-ins requires adding values to the shared_preload_libraries parameter in advance. You can log in to the TencentDB for PostgreSQL console, click Instance ID, then enter the parameter setting webpage, search for the shared_preload_libraries parameter, and click 
﻿
 to modify it.
Note:
**Note:** After editing and saving shared_preload_libraries, the instance will restart to modify parameters. The specific time depends on business conditions. Ensure your application has an automatic reconnection feature.
If the selectable parameter values of shared_preload_libraries do not include the plugin you need to create, but you find the plugin information in Procedure 1, you do not need to modify the parameter value and can directly create the plugin.
﻿
Select the plug-in you need and click 
﻿
 to save. In this example, the vector plug-in is not included in the shared_preload_libraries parameter value, so you only need to create it directly.
﻿
Creating a Plugin
Log in to the database instance and execute the following statement in the database that requires the use of the plug-in:
CREATE EXTENSION vector;
Note:
Warning: Please try to avoid creating plugins in the postgres system database to avoid potential security risks.
After execution, confirm it by viewing the following statement to check whether creation succeeded.
SELECT * FROM pg_available_extensions WHERE name = 'vector';
The installed_version matches the default_version, indicating the add-on creation was successful.
﻿

postgres_fdw Extension for Cross-database Access

Last updated：2024-01-24 11:16:51

TencentDB for PostgreSQL provides extensions for accessing external data sources, including other databases in the same instance and other instances. The cross-database access extensions include homogeneous extensions (dblink and postgresql_fdw) and heterogeneous extensions (mysql_fdw and cos_fdw). You can enable cross-database access by following steps below:
1. Install the extensions by running CREATE EXTENSION.
2. Create a foreign server object and create link maps for each remote database that needs to be connected.
3. Use the corresponding command to access external tables to get the data.
As the cross-database access extensions can directly access across instances or perform cross-database access in the same instance, TencentDB for PostgreSQL optimizes access control over the creation of foreign server objects and implements categorized management based on the environment of the target instance. Auxiliary parameters are added to the open-source edition to verify user identity and adjust network policies. For more information, see Auxiliary Parameters.
Auxiliary Parameters
host
This parameter is required for cross-instance access. IP address of the target instance
port
This parameter is required for cross-instance access. Port of the target instance.
instanceid
Instance ID
This parameter is required for access across TencentDB for PostgreSQL instances. It is in the format of postgres-xxxxxx or pgro-xxxxxx and can be viewed in the console.
If the target instance is in a CVM instance, this parameter is the ID of the CVM instance in the format of ins-xxxxx.
dbname 
Name of the database in the remote PostgreSQL service to be accessed. For cross-database access in the same instance, you only need to configure this parameter and can leave other parameters empty.
access_type
This parameter is optional.  Target instance types:
The target instance is a TencentDB for PostgreSQL or TencentDB for MySQL instance; if no other types are explicitly specified, this will be the default type.
The target instance is in a CVM instance.
The target instance is a self-built instance with public IP in Tencent Cloud.
The target instance is a Tencent Cloud VPN-based instance.
The target instance is a self-built VPN-based instance.
The target instance is a Direct Connect-based instance.
uin
This parameter is optional. ID of the account to which the instance belongs, which is used to verify user permissions and can be viewed in Account Info.
own_uin
This parameter is optional. ID of the root account to which the instance belongs, which is also needed for verifying user permissions.
vpcid
This parameter is optional. VPC ID. It is required if the target instance is in a CVM instance in a VPC. It can be viewed in the VPC console.
subnetid
This parameter is optional. VPC subnet ID. It is required if the target instance is in a CVM instance in a VPC. It can be viewed in the VPC console.
dcgid
This parameter is optional. Direct Connect connection ID. It is required if the target instance is connected to the network over Direct Connect.
vpngwid
This parameter is optional. VPN gateway ID. It is required if the target instance is connected to the network over VPN.
region
This parameter is optional. It indicates the region where the target instance resides; for example, "ap-guangzhou" represents the Guangzhou region. It is required for cross-region access.
Sample for Using postgres_fdw
The postgres_fdw extension can be used to access data from other databases in the same instance or other instances.
Step 1. Prepare
1. Create test data in the instance.
postgres=>create role user1 with LOGIN  CREATEDB PASSWORD 'password1';
postgres=>create database testdb1;
CREATE DATABASE
Note:
 If an error occurs during creation, submit a ticket for assistance.
2. Create test data in the target instance.
postgres=>create role user2 with LOGIN  CREATEDB PASSWORD 'password2';
postgres=> create database testdb2;
CREATE DATABASE
postgres=> \c testdb2 user2
You are now connected to database "testdb2" as user "user2".
testdb2=> create table test_table2(id integer);
CREATE TABLE
testdb2=> insert into test_table2 values (1);
INSERT 0 1
Step 2. Create the postgres_fdw extension
Note:
If you are prompted that the extension does not exist or you have insufficient permissions during creation, submit a ticket for assistance.
# Create
postgres=> \c testdb1
You are now connected to database "testdb1" as user "user1".
testdb1=> create extension postgres_fdw;
CREATE EXTENSION
# View
testdb1=> \dx
                            List of installed extensions
      Name     | Version |   Schema   |                    Description
--------------+---------+------------+----------------------------------------------------
  plpgsql      | 1.0     | pg_catalog | PL/pgSQL procedural language
  postgres_fdw | 1.0     | public     | foreign-data wrapper for remote PostgreSQL servers
(2 rows)
Step 3. Create a server
Note:
Cross-instance access is supported only for kernel v10.17_r1.2, v11.12_r1.2, v12.7_r1.2, v13.3_r1.2, v14.2_r1.0, and later.
Cross-instance access
# Access the data of the target instance's `testdb2` from the current instance's `testdb1`
testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', instanceid 'postgres-xxxxx');
CREATE SERVER
For cross-database access in the same instance, you only need to enter the dbname parameter.
# Access the data of `testdb2` from `testdb1` in the current instance
create server srv_test1 foreign data wrapper postgres_fdw options (dbname 'testdb2');
The target instance is in a CVM instance in the classic network.
  testdb1=>create server srv_test foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx', dbname 'testdb2', port '5432', instanceid 'ins-xxxxx', access_type '2', region 'ap-guangzhou'，uin 'xxxxxx'，own_uin 'xxxxxx');
  CREATE SERVER
The target instance is in a CVM instance in a VPC.
  testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', instanceid 'ins-xxxxx', access_type '2', region 'ap-guangzhou', uin 'xxxxxx', own_uin 'xxxxxx', vpcid 'vpc-xxxxxx', subnetid 'subnet-xxxxx');
  CREATE SERVER
The target instance is a self-built instance with public IP in Tencent Cloud.
  testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', access_type '3', region 'ap-guangzhou', uin 'xxxxxx', own_uin 'xxxxxx');
  CREATE SERVER 
The target instance is a Tencent Cloud VPN-based instance.
  testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', access_type '4', region 'ap-guangzhou', uin 'xxxxxx', own_uin 'xxxxxx', vpngwid 'xxxxxx');
The target instance is a self-built VPN-based instance.
  testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', access_type '5', region 'ap-guangzhou', uin 'xxxxxx', own_uin 'xxxxxx', vpngwid 'xxxxxx');   
The target instance is a Direct Connect-based instance.
  testdb1=>create server srv_test1 foreign data wrapper postgres_fdw options (host 'xxx.xxx.xxx.xxx',dbname 'testdb2', port '5432', access_type '6', region 'ap-guangzhou', uin 'xxxxxx', own_uin 'xxxxxx', dcgid 'xxxxxx');    
  CREATE SERVER       
Step 4. Create a user mapping
Note:
 You can skip this step for cross-database access in the same instance.
testdb1=> create user mapping for user1 server srv_test1 options (user 'user2',password 'password2');
CREATE USER MAPPING
Step 5. Create a foreign table
testdb1=> create foreign table foreign_table1(id integer) server srv_test1 options(table_name 'test_table2');
CREATE FOREIGN TABLE
Step 6. Access data from foreign table
testdb1=> select * from foreign_table1;
  id
----
   1
(1 row)
References
postgres_fdw Overview
Create a server on v9.3
Create a server on v9.5
Create a server on v10
Create a server on v11
Create a server on v12
Create a server on v13
Create a server on v14
Sample for Using dblink
Step 1. Create the dblink extention
postgres=> create extension dblink;
postgres=> \dx
                                         List of installed extensions
        Name | Version | Schema | Description                            
--------------------+---------+------------+-------------------------------------------------------------------
 dblink             | 1.2     | public     | connect to other PostgreSQL databases from within a database
 pg_stat_log        | 1.0     | public     | track runtime execution statistics of all SQL statements executed
 pg_stat_statements | 1.6 | public | track execution statistics of all SQL statements executed
 plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(4 rows)
Step 2. Create the dblink link
select dblink_connect('yunpg1','host=10.10.10.11 port=5432 instanceid=postgres-2123455r dbname=postgres access_type=1 user=dbadmin password=P302!');
 dblink_connect 
----------------
 OK
(1 row)
Step 3. Access external data
postgres=> select * from dblink('yunpg1','select catalog_name,schema_name,schema_owner from information_schema.schemata') as t(a varchar(50),b varchar(50),c varchar(50));
    a     |         b          |    c    
----------+--------------------+---------
 postgres | pg_toast           | user_00
 postgres | pg_temp_1          | user_00
 postgres | pg_toast_temp_1    | user_00
 postgres | pg_catalog         | user_00
 postgres | public             | user_00
 postgres | information_schema | user_00
(6 rows)
References
﻿dblink Overview﻿
Sample for Using mysql_fdw
Step 1. Create the mysql_fdw extension
postgres=> create extension mysql_fdw;
CREATE EXTENSION
postgres=> \dx;
                                            List of installed extensions
        Name | Version | Schema | Description                               
--------------------+---------+------------+------------------------------------------------------------------------
 dblink             | 1.2     | public     | connect to other PostgreSQL databases from within a database
 mysql_fdw    | 1.1     | public     | Foreign data wrapper for querying a MySQL server
 pg_stat_log        | 1.0     | public     | track runtime execution statistics of all SQL statements executed
 pg_stat_statements | 1.9     | public     | track planning and execution statistics of all SQL statements executed
 plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(5 rows)
Step 2. Create a server
postgres=> CREATE SERVER mysql_svr  FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host '171.16.10.13',port '3306',instanceid 'cdb-l1d95grp',uin '100026380431');
CREATE SERVER
Step 3. Create a user mapping
postgres=> CREATE USER MAPPING FOR PUBLIC SERVER mysql_svr OPTIONS (username 'fdw_user',password 'Secret!123');
CREATE USER MAPPING
Step 4. Access external data
postgres=> IMPORT FOREIGN SCHEMA hrdb FROM SERVER mysql_svr INTO public;
References
mysql_fdw Overview
Sample for Using cos_fdw
For samples of using cos_fdw, see Supporting Tiered Storage Based on cos_fdw Extension.
Note
Pay attention to the following for the target instance:
1. The hba in PostgreSQL needs to be modified to allow the created mapped user (e.g., user2) to access via MD5. For more information on how to modify hba, see PostgreSQL's official documentation.
2. If the target instance is not a TencentDB instance and has a hot backup mode configured, after a primary-standby switch, you need to update the server connection address or create a server again.

pg_roaringbitmap Extension for Bitwise Operation

Last updated：2024-01-24 11:16:51

TencentDB for PostgreSQL provides the pg_roaringbitmap extension to use the bitwise operation feature to improve the query performance.
Prerequisites
Your TencentDB for PostgreSQL instance is on v10, 11, 12, 13, 14 or 15.
Background
The roaring bitmap algorithm divides a 32-bit INT value into 216 data chunks, each of which corresponds to the higher 16 bits of an integer and uses a container to store the lower 16 bits.
Roaring bitmap stores the containers in a dynamic array as a level-1 index. Containers are in two different structures: array container for sparse chunks and bitmap container for dense chunks. If a container has less than 4,096 integers, the values are stored in an array container; otherwise, the values are stored in a bitmap container.
By using this storage structure, roaring bitmap can quickly search for a specific value. During bitwise operations (AND, OR, and XOR), roaring bitmap provides the corresponding algorithms to efficiently implement operations between two containers, making it powerful in both storage and computing performance.
Directions
1. Run the following command to create an extension:
CREATE EXTENSION roaringbitmap;
2. Run the following command to create a table with data of roaringbitmap type:
CREATE TABLE t1 (id integer, bitmap roaringbitmap);
3. Run the following command to use the rb_build function to insert the roaringbitmap data:
-- Set the bit value of the array to 1.
INSERT INTO t1 SELECT 1,RB_BUILD(ARRAY[1,2,3,4,5,6,7,8,9,200]);
-- Set the bit values of multiple records to 1 and aggregate the bit values into a Roaring bitmap.  
INSERT INTO t1 SELECT 2,RB_BUILD_AGG(e) FROM GENERATE_SERIES(1,100) e;
4. Run the following command to perform bitwise operations (OR, AND, XOR, and ANDNOT):
-- Set the bit value of the array to 1.
SELECT RB_OR(a.bitmap,b.bitmap) FROM (SELECT bitmap FROM t1 WHERE id = 1) AS a,(SELECT bitmap FROM t1 WHERE id = 2) AS b;
5. Run the following command to perform aggregated bitwise operations (OR, AND, XOR, and BUILD) to generate a new Roaring bitmap:
SELECT RB_OR_AGG(bitmap) FROM t1;
SELECT RB_AND_AGG(bitmap) FROM t1;
SELECT RB_XOR_AGG(bitmap) FROM t1;
SELECT RB_BUILD_AGG(e) FROM GENERATE_SERIES(1,100) e;
6. Run the following command to calculate the cardinality, i.e., number of bits set to 1 in the Roaring bitmap:
SELECT RB_CARDINALITY(bitmap) FROM t1;
7. Run the following command to return the subscripts of the bits set to 1 in the Roaring bitmap:
SELECT RB_ITERATE(bitmap) FROM t1 WHERE id = 1;
Feature Function List
Function
Input
Output
Description
Example
Result
rb_build
integer[]
roaringbitmap
Create roaringbitmap from integer array
rb_build('{1,2,3,4,5}')
{1,2,3,4,5}
rb_index
roaringbitmap,integer
bigint
Return the 0-based index of element in this roaringbitmap, or -1 if do not exsits
rb_index('{1,2,3}',3)
2
rb_cardinality
roaringbitmap
bigint
Return cardinality of the roaringbitmap
rb_cardinality('{1,2,3,4,5}')
5
rb_and_cardinality
roaringbitmap,roaringbitmap
bigint
Return cardinality of the AND of two roaringbitmaps
rb_or_cardinality('{1,2,3}','{3,4,5}')
1
rb_xor_cardinality
roaringbitmap,roaringbitmap
bigint
Return cardinality of the XOR of two roaringbitmaps
rb_xor_cardinality('{1,2,3}','{3,4,5}')
4
rb_andnot_cardinality
roaringbitmap,roaringbitmap
bigint
Return cardinality of the ANDNOT of two roaringbitmaps
rb_andnot_cardinality('{1,2,3}','{3,4,5}')
2
rb_is_empty
roaringbitmap
boolean
Check if roaringbitmap is empty.
rb_is_empty('{1,2,3,4,5}')
t
rb_fill
roaringbitmap,range_start bigint,range_end bigint
roaringbitmap
Fill the specified range (not include the range_end)
rb_fill('{1,2,3}',5,7)
{1,2,3,5,6}
rb_clear
roaringbitmap,range_start bigint,range_end bigint
roaringbitmap
Clear the specified range (not include the range_end)
rb_clear('{1,2,3}',2,3)
{1,3}
rb_flip
roaringbitmap,range_start bigint,range_end bigint
roaringbitmap
Negative the specified range (not include the range_end)
rb_flip('{1,2,3}',2,10)
{1,4,5,6,7,8,9}
rb_range
roaringbitmap,range_start bigint,range_end bigint
roaringbitmap
Return new set with specified range (not include the range_end)
rb_range('{1,2,3}',2,3)
{2}
rb_range_cardinality
roaringbitmap,range_start bigint,range_end bigint
bigint
Return the cardinality of specified range (not include the range_end)
rb_range_cardinality('{1,2,3}',2,3)
1
rb_min
roaringbitmap
integer
Return the smallest offset in roaringbitmap. Return NULL if the bitmap is empty
rb_min('{1,2,3}')
1
rb_max
roaringbitmap
integer
Return the greatest offset in roaringbitmap. Return NULL if the bitmap is empty
rb_max('{1,2,3}')
3
rb_rank
roaringbitmap,integer
bigint
Return the number of elements that are smaller or equal to the specified offset
rb_rank('{1,2,3}',3)
3
rb_jaccard_dist
roaringbitmap,roaringbitmap
double precision
Return the jaccard distance(or the Jaccard similarity coefficient) of two bitmaps
rb_jaccard_dist('{1,2,3}','{3,4}')
0.25
rb_select
roaringbitmap,bitset_limit bigint,bitset_offset bigint=0,reverse boolean=false,range_start bigint=0,range_end bigint=4294967296
roaringbitmap
Return subset [bitset_offset,bitset_offset+bitset_limit) of bitmap between range [range_start,range_end)
rb_select('{1,2,3,4,5,6,7,8,9}',5,2)
{3,4,5,6,7}
rb_to_array
roaringbitmap
integer[]
Convert roaringbitmap to integer array
rb_to_array(roaringbitmap('{1,2,3}'))
{1,2,3}
rb_iterate
roaringbitmap
SET of integer
Return set of integer from a roaringbitmap data.
SELECT rb_iterate(rb_build('{1,2,3}'))
1
2
3
Aggregate Function List
Aggregate Function
Input
Output
Description
Example
Result
rb_build_agg
integer
roaringbitmap
Build a roaringbitmap from a integer set
select rb_build_agg(id) from (values (1),(2),(3)) t(id) 
{1,2,3}
rb_or_agg
roaringbitmap
roaringbitmap
AND Aggregate calculations from a roaringbitmap set
select rb_or_agg(bitmap)  from (values (roaringbitmap('{1,2,3}')), (roaringbitmap('{2,3,4}')) ) t(bitmap)
{1,2,3,4}
rb_and_agg
roaringbitmap
roaringbitmap
AND Aggregate calculations from a roaringbitmap set
select rb_and_agg(bitmap)  from (values (roaringbitmap('{1,2,3}')), (roaringbitmap('{2,3,4}')) ) t(bitmap)
{2,3}
rb_xor_agg
roaringbitmap
roaringbitmap
XOR Aggregate calculations from a roaringbitmap set
select rb_xor_agg(bitmap) from (values (roaringbitmap('{1,2,3}')), (roaringbitmap('{2,3,4}')) ) t(bitmap)
{1,4}
rb_or_cardinality_agg
roaringbitmap
bigint
OR Aggregate calculations from a roaringbitmap set, return cardinality.
select rb_or_cardinality_agg(bitmap)  from (values (roaringbitmap('{1,2,3}')),(roaringbitmap('{2,3,4}'))) t(bitmap)
4
rb_and_cardinality_agg
roaringbitmap
bigint
AND Aggregate calculations from a roaringbitmap set, return cardinality
select rb_and_cardinality_agg(bitmap)  from (values (roaringbitmap('{1,2,3}')),  (roaringbitmap('{2,3,4}'))) t(bitmap)
2
rb_xor_cardinality_agg
roaringbitmap
bigint
XOR Aggregate calculations from a roaringbitmap set, return cardinality
select rb_xor_cardinality_agg(bitmap)   from (values (roaringbitmap('{1,2,3}')), (roaringbitmap('{2,3,4}')) ) t(bitmap)
2
﻿

Network Management

Overview

Last updated：2024-01-24 11:16:51

This document describes the network of TencentDB for PostgreSQL. TencentDB for PostgreSQL offers the network management feature to protect your instance security and provide service to internal and external businesses efficiently and freely.
Network Types
There are two types of TencentDB network environments: VPC and classic network.
VPC: it is a logically isolated network space that can be customized in Tencent Cloud. Even in the same region, different VPCs cannot communicate with each other by default. Similar to the traditional network in an IDC, a VPC is where your Tencent Cloud service resources are managed.
Classic network: it is the public network resource pool for all Tencent Cloud users. All your Tencent Cloud resources will be centrally managed by Tencent Cloud.
Note: 
Currently, resources cannot be created in the classic network.
Feature comparison
Feature
Classic Network
VPC
Custom network
Unsupported
Supported
Custom routing
Unsupported
Supported
Custom IP
Unsupported
Supported
Interconnection rule
Interconnection in the same region
Interconnection between subnets in the same VPC in the same region
Security control
Security group
Security group
Network Access
Tencent Cloud services can be accessed over both the public and private networks.
Public network access: it is a service provided by Tencent Cloud to implement public data transfer for an instance. You can enable the public IP of the instance for it to communicate with other computers and allow access over the public network.
Private network access: it is used to provide Local Area Network (LAN) service. Tencent Cloud assigns resources with private IP addresses to allow a free private network communication in the same region or instance access over the private network.
Note: 
Security groups that currently support public network access are available only in the Guangzhou, Shanghai, Beijing, and Chengdu regions. Instances in other regions may be attacked if the public network access is enabled. We do not recommend that you enable public network access for instances in production environment. If you need to enable public network access, security group rules must be configured.
Network Configuration
You can configure one or two networks for each TencentDB for PostgreSQL instance.
In scenarios where the instance supports two networks:
An instance can be accessed through different VIPs that belong to different VPCs and subnets.
You can use this feature to change the instance network, for example, from the classic network to VPC or from VPC A to VPC B.
You can use this feature to implement the multi-plane network feature in scenarios where businesses in two different VPCs need to access the same database instance.
Managing Instance Network
You can add, delete, and change networks in the TencentDB for PostgreSQL console. For more information, see Modifying Network.

Modifying Network

Last updated：2024-01-24 11:16:51

This document describes how to configure and manage instance networks in the TencentDB for PostgreSQL console. You can add, delete, and modify instance networks based on your business needs.
Overview
Tencent Cloud supports classic network and VPC, which are capable of offering a diversity of smooth services. On this basis, we provide more flexible services as shown below to help you configure and manage network connectivity with ease.
Changing network
Switch from classic network to VPC: a single TencentDB source instance can be switched from classic network to VPC.
Switch from VPC A to VPC B: a single primary or read-only TencentDB instance can be switched from VPC A to VPC B.
Customizing access IP address
Custom primary instance IP: you can specify the IP address when adding a network on the instance details page of the primary instance.
Custom read-only instance IP: you can specify the IP address when adding a network on the instance details page of a read-only instance.
Notes
The change from classic network to VPC is irreversible. After the switch to a VPC, the TencentDB instance cannot communicate with Tencent Cloud services in another VPC or classic network.
After you change a primary instance's network, the networks of read-only instances associated with the primary instance won't be automatically switched; that is, you need to separately switch them.
A new network added to an instance does not affect the IP address in the original network configuration.
Directions
Adding network
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance details page, click Add Network in Basic Info > Network.
﻿
3. In the pop-up window, select a network. You can let the system automatically set an IP or manually specify an IP. After confirming that everything is correct, click OK.
Note: 
You can configure one or two networks for each instance.
If an instance has two networks, both are controlled by the security group associated with the instance.
You can only select a new VPC and subnet in the same region where the instance resides.
﻿
4. After the instance status changes from Changing network to Running, you can query the changed instance network on the instance details page.
Deleting network
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance details page, click Delete Network in Basic Info > Network.
﻿
﻿
3. In the pop-up window, select the network to be deleted and click OK.
Note: 
You can configure one or two networks for each instance.
You must confirm that a network is no longer required before deleting it, as you will not be able to access an instance over a deleted network.
﻿
4. After the instance status changes from Changing network to Running, you can query the changed instance network on the instance details page.
Modifying network
If you want to change the current network of the instance, for example, from the classic network to a VPC or from VPC A to VPC B, you can add and delete a network as detailed above for this need.
Example 1: changing from classic network to VPC
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance details page, click Add Network in Basic Info > Network, select the target VPC, and click OK.
3. After the instance status becomes Running, click Delete Network after the instance network, select the classic network, and click Delete. At this point, the instance network has changed from the original classic network to the new VPC.
Example 2: changing from VPC A to VPC B
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click an instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance details page, click Add Network in Basic Info > Network, select VPC B, and click OK.
3. After the instance status becomes Running, click Delete Network after the instance network, select VPC A, and click Delete. At this point, the instance network has changed from VPC A to VPC B.
Note: 
After a network is deleted, you cannot access the instance over it. Make sure that a network is no longer needed before deleting it.

Enabling Public Network Address

Last updated：2025-04-23 21:44:46

TencentDB for PostgreSQL supports private and public network addresses. By default, a private network address is provided for you to access your instance over the private network. If you want to enable public network access, you can enable it in the console to build a public network address.
Note: 
Currently, the Beijing, Chengdu, Guangzhou, Hong Kong (China), Nanjing, Shanghai, Tokyo, and Silicon Valley regions support the public network feature and support enabling the public network address through the console.
Note: There are risks of attacks once the public network is enabled. Operate with caution.
To enable the public network address, you need to configure security group rules to access it.
Enabling Public Network Address in Console
Note:
Failures occurring during public network access will not be included in the overall availability calculation of the TencentDB for PostgreSQL service.
Access over public network reduces instance security. It is only recommended for management, database testing, or auxiliary management. No availability SLA guarantee is provided. Use private network for business access.
Recommend you use the public network domain name instead of the IP for access. Because adjustment of database instance specifications, reactivation of the public network, and network upgrades may cause changes to the public network IP. Using the public network domain name for access can ensure minimal impact on business and eliminates the need to modify the application.
1. Log in to the TencentDB for PostgreSQL console and select the region. In the instance list, click the Instance ID or Manage in the Operation column to enter the instance management page.
2. On the Instance Details page, click Enable in Basic Info > Public IPv4 Address.
﻿
3. In the pop-up window, read the notes and click OK.
4. After the instance status is updated to Running, you can view the public network address on the instance details page.
Configure a TencentDB for PostgreSQL security group
1. Log in to the TencentDB for PostgreSQL console and select the region. In the instance list, click the Instance ID or Manage in the Operation column to enter the instance management page.
2. On the instance management page, select the Security Group tab, click Configure Security Group, configure the security group rule to open all ports, and confirm that the security group allows access from public IPs. For more information on configuration, see Managing Security Groups.
﻿
Check public network connectivity
You can use a client tool to access TencentDB for PostgreSQL. For detailed directions, see Connecting to PostgreSQL Instances.

Enabling Public Network Services Through CLB

Last updated：2025-11-11 19:04:10

TencentDB for PostgreSQL supports two address types: private network address and public network address. The private network address is provided by default for internal access to the instance. If public network access is required, you can enable the public network address via the Console or enable public network services through Cloud Load Balancer (CLB).
This introduces the method to enable public network services through CLB and connect to the instance via the pgAdmin client.
Note:
Currently, public network addresses can be enabled through the console in the following regions: Beijing, Chengdu, Guangzhou, Hong Kong (China), Nanjing, Shanghai, Tokyo, and Silicon Valley.
- After enabling the public network address, you must configure security group rules to access.
Prerequisites
Applied for backend service feature usage. Please submit a ticket to CLB to apply for backend service feature usage.
The CLB service has been purchased. For specific steps, please see CLB purchase method.
Note:
When purchasing the CLB service, select the service region where TencentDB for PostgreSQL is located.
Only public network CLB instances support backend service functionality. The network type must be set to public network.
Note: When creating a CLB instance, please ensure it belongs to the same VPC as the TencentDB for PostgreSQL instance. If they are in different VPCs, configure CCN to connect the private networks after creating the CLB instance. For details, please refer to Configure CCN.
Step 1: Enable CLB Backend Service
Enable cross-VPC access so that the CLB instance can be bound to another private IP.
Log in to the CLB console, select the region, and click the target instance ID in the instance list to enter the instance management page.
On the Basic Info page, click Configure in the Real Server section.
In the pop-up window, click Submit.
Step 2: Configure CLB Service
On the instance management page, select Listener Management, and click Create under TCP/UDP/TCP SSL/QUIC listener.
﻿
In the pop-up dialog box, complete the settings step by step, and finally click Submit to complete the creation.
﻿
After creation, click the just created listener, then click Bind.
In the pop-up dialog box, select the target type as IP Type, click Add Private IP, input the private IP address and port of the PostgreSQL instance to be connected, then click OK to complete the binding.
Note:
If unable to bind, Submit a Ticket for assistance.
Step 3: Configure TencentDB for PostgreSQL Security Group
Log in to the TencentDB for PostgreSQL console, select a region, and click Instance ID or Operation > Manage in the instance list to enter the instance management page.
On the instance management page, select the Security Group tab, click Configure Security Group, add a new security group, set the security group rules to allow all ports, and confirm the security group permits public IP access. For detailed configuration methods, please refer to Manage Security Group.
﻿
﻿
Step 4: Connecting to an Instance Via pgAdmin Client
Enter the pgAdmin client official download page, choose to download based on your OS type, and complete installation.
﻿
After installation, open pgAdmin4, click Add New Server on the homepage, and fill in the instance information to be connected.
﻿
The information description is as follows:
Parameter
Description
Host name/address
Enter the address of the CLB instance. You can view the VIP information in the basic info on the CLB instance details page.
Port
Enter the port of the CLB instance. You can view the TCP port number under Monitor Management on the CLB instance details page.
Username
Enter the account name of the PostgreSQL instance to be connected. The account is created under Instance Management > Database Management > Account Management.
Password
Enter the password corresponding to the filled-in Username, then click Save.
﻿
Connection successful. The interface is shown in the figure below.
﻿

Access Management

Overview

Last updated：2024-01-24 11:16:51

Known Issues
If you have multiple users managing different Tencent Cloud services such as CVM, VPC, TencentDB for PostgreSQL, and other TencentDB products, and they all share your Tencent Cloud account access key, you may face the following problems:
The risk of your key being compromised is high since multiple users are sharing it.
Your users might introduce security risks from misoperations due to the lack of user access control.
Solutions
You can avoid the problems above by allowing different users to manage different services through sub-accounts. By default, a sub-account does not have permissions to use TencentDB for PostgreSQL or its resources. Therefore, you need to create a policy to grant different permissions to the sub-accounts.
Cloud Access Management (CAM) is a Tencent Cloud service that helps you securely manage and control access to your Tencent Cloud resources. Using CAM, you can create, manage, and terminate users and user groups. You can manage identities and policies to allow specific users to access your Tencent Cloud resources.
When using CAM, you can associate a policy with a user or user group to allow or forbid them to use specified resources to complete specified tasks. For more information on CAM policies, please see Element Reference.
You can skip this section if you do not need to manage permissions to PostgreSQL resources for sub-accounts. This will not affect your understanding and use of the other sections of the document.
Getting started
A CAM policy is used to allow or deny one or more PostgreSQL instance operations. When configuring a policy, you must specify the target resources of the operations, which can be all resources or specified resources. A policy can also include conditions where the resources can be used.
Some PostgreSQL APIs do not support resource-level permissions, which means that you cannot specify resources when using those APIs.
Task
Link
Understand the basic structure of policies
Access Policy Syntax > Policy Syntax
Define operations in a policy
Access Policy Syntax > PostgreSQL Operations
Define resources in a policy
Access Policy Syntax > PostgreSQL Resource Paths
View supported resource-level permissions
Authorizable Resource Types
View console examples
Console Examples
﻿

Access Policy Syntax

Last updated：2024-01-24 11:16:51

Policy Syntax
CAM policy:
{	 
        "version":"2.0", 
        "statement": 
        [ 
           { 
              "effect":"effect", 
              "action":["action"], 
              "resource":["resource"], 
               "condition": {"key":{"value"}} 
           } 
       ] 
} 
version is required. Currently, only the value "2.0" is allowed.
statement describes the details of one or more permissions, and therefore contains the permission(s) other elements such as effect, action, resource, and condition. One policy has only one statement.
effect is required. It describes the result of a statement. The result can be "allow" or an explicit "deny".
action is required. It describes the allowed or denied operation. An operation can be an API or a feature set (a set of specific APIs prefixed with "permid").
resource is required. It describes the details of authorization. A resource is described in a six-segment format. Detailed resource definitions vary by product.
condition describes the condition for the policy to take effect. Conditions consist of operators, operation keys, and operation values. PostgreSQL currently does not support special conditions, so this element can be left empty.
PostgreSQL Operations
You can use CAM policy statements to authorize any API operations for any services that support CAM. To authorize PostgreSQL operations, please specify the APIs prefixed with "postgres:", such as "postgres:DescribeDBInstances" and "postgres:DescribeDBInstanceAttribute".
To specify multiple operations in a single statement, separate them with commas as shown below:
"action":["postgres:action1","postgres:action2"]
You can also specify multiple operations using a wildcard. For example, you can specify all operations whose names begin with "Describe" as shown below:
"action":["postgres:Describe*"]
To specify all PostgreSQL operations, use the wildcard (*) as shown below:
"action":["postgres:*"]
PostgreSQL Resource Paths
Each CAM policy statement for PostgreSQL is resource-specific.
The general form of a resource path is as follows:
qcs:project_id:service_type:region:account:resource
project_id describes the project information, which is only used to enable compatibility with legacy CAM logic and can be left empty.
service_type describes the abbreviated service name, such as "postgres".
region describes the region information, such as "ap-shanghai".
account: the root account information of the resource owner (which is the "Account ID" on the Account Information page), such as "164xxx472".
resource describes detailed resource information of each product, such as "DBInstanceId/postgres-0xssvm8e" or "DBInstanceId/*". The table below describes the resources that can be used by PostgreSQL and the corresponding resource description methods.
Resource
Resource Description Method in Access Policies
Instance
qcs::postgres:$region:$account:DBInstanceId/$DBInstanceId
For example, you can specify an instance (instance ID: postgres-0xssvm8e) in the statement as shown below:
"resource":[ "qcs::postgres:ap-shanghai:164xxx472:DBInstanceId/postgres-0xssvm8e"]
You can also use the wildcard (*) to specify all instances in the Shanghai region that belong to a specific account as shown below:
"resource":[ "qcs::postgres:ap-shanghai:164xxx472:DBInstanceId/*"]
If you want to specify all resources or if a specific API operation does not support resource-level permission control, you can use the wildcard (*) in the resource element as shown below:
"resource": ["*"]
To specify multiple resources in a single statement, separate them with commas. In the following example, we specified two instances:
"resource":["qcs::postgres::164xxx472:DBInstanceId/postgres-0xf1f41e","qcs::postgres::164xxx472:DBInstanceId/postgres-0xssvm8e"]
﻿

Authorizable Resource Types

Last updated：2024-01-24 11:16:51

Resource-Level Permission Overview
Resource-level permissions specify resources a user can operate. TencentDB for PostgreSQL supports specific resource-level permissions, i.e., allowing the user to perform operations or use specific resources.
In Cloud Access Management (CAM), the types of PostgreSQL resources that can be authorized are as follows:
Resource Type
Resource Description Method in Access Policies
Instance
 qcs::postgres:$region:$account:DBInstanceId/$DBInstanceId 
 qcs::postgres:$region:$account:DBInstanceId/*  
The PostgreSQL instance APIs section in this document describes PostgreSQL API operations that currently support resource-level permissions as well as resources and condition keys supported by each operation. When configuring the resource path, you need to replace values of the parameters such as $region and $account with your actual values. You can also use the wildcard (*) in the path. For more information, please see Console Examples.
Note: 
For a PostgreSQL API operation that does not support authorization at the resource level, you can still authorize a user to perform the operation. In this case, you must specify * as the resource element in the policy statement.
List of APIs Not Supporting Resource-Level Permissions
API Operation
API Description
CreateDBInstances
Creates an instance
CreateServerlessDBInstance
Creates a PostgreSQL for Serverless instance
DescribeOrders
Obtains order information
DescribeRegions
Queries available regions
DescribeZones
Queries available availability zones
DescribeProductConfig
Queries product specifications
InquiryPriceCreateDBInstances
Queries prices
DescribeServerlessDBInstances
Queries the list of PostgreSQL for Serverless instances
List of APIs Supporting Resource-Level Permissions
[PostgreSQL instance APIs]
PostgreSQL for Serverless instance APIs
API Name
API Description
CloseServerlessDBExtranetAccess
Disables the public network access for a PostgreSQL for Serverless instance
DeleteServerlessDBInstance
Deletes a PostgreSQL for Serverless instance
OpenServerlessDBExtranetAccess
Enables the public network access for a PostgreSQL for Serverless instance
Backup and restoration APIs
API Name
API Description
DescribeDBBackups
Queries the list of instance backups
DescribeDBErrlogs
Obtains error logs
DescribeDBSlowlogs
Obtains slow query logs
DescribeDBXlogs
Obtains the Xlog list
Instance APIs
API Name
API Description
CloseDBExtranetAccess
Disables the public network address for an instance
DescribeDBInstanceAttribute
Queries instance details
DescribeDatabases
Pulls the instance list
DestroyDBInstance
Terminates an instance
InitDBInstances
Initializes an instance
InquiryPriceRenewDBInstance
Queries the instance renewal price
InquiryPriceUpgradeDBInstance
Queries the instance upgrade price
ModifyDBInstanceName
Modifies the instance name
ModifyDBInstancesProject
Transfers an instance to another project
OpenDBExtranetAccess
Enables public network access
RenewInstance
Renews an instance
RestartDBInstance
Restarts an instance
SetAutoRenewFlag
Sets auto-renewal
UpgradeDBInstance
Upgrades an instance
DescribeDBInstances
Queries the instance list
Account APIs
API Name
API Description
DescribeAccounts
Obtains the list of instance users
ModifyAccountRemark
Modifies the account password
ResetAccountPassword
Resets the account password
﻿

Console Examples

Last updated：2025-09-10 22:18:28

Overview
You can grant a user permissions to view and use specific resources in the TencentDB for PostgreSQL console by using Cloud Access Management (CAM) policies. This document provides examples to describe how to create and use such policies to grant these permissions.
Directions
Note: 
To grant a user only the permissions of specific APIs, at least the permissions of the following APIs must be granted, or else the console fails to display correctly.
The sample code of action is as follows:
"action":  [
"postgres:DescribeProductConfig",
"postgres:InquiryPriceCreateDBInstances",
"postgres:DescribeRegions",
"postgres:DescribeZones"
]
To grant a user the permissions to monitor and view instances, the API permissions related to monitoring needs to be granted. The sample code of action is as follows:
{"effect": "allow",
"action":  [
"monitor:Get*",
"monitor:Describe*"
],
"resource": "*"
}
Full read/write permission policy for PostgreSQL
To grant a user permissions to create and manage PostgreSQL instances, you can associate the QcloudPostgreSQLFullAccess policy with the user.
This policy grants the user permissions to operate all PostgreSQL resources. You can find more details below:
Associate the default policy QcloudPostgreSQLFullAccess with the user as instructed in Authorization Management.
Read-only permission policy for PostgreSQL
To grant a user permissions to only view PostgreSQL instances, you can associate the QcloudPostgreSQLReadOnlyAccess policy with the user. Users assigned will not have the access to create, delete, or modify PostgreSQL instances.
This policy grants the user permissions of all PostgreSQL operations that begin with the word "Describe" or "Inquiry". The detailed steps are as follows:
Associate the default policy PostgreSQL with the user as instructed in Authorization Management.
Policy for granting a user permissions to operate specific PostgreSQL instances
To grant a user permissions to operate specific PostgreSQL instances, you can associate the following policy with the user. The detailed steps are as follows:
1. Create a custom policy as instructed in Policy.
The example policy syntax is as follows. This example policy grants a user permissions of all operations on the PostgreSQL instance whose ID is "postgres-0xxxx8e".
{
 "version": "2.0",
 "statement": [
     {
         "action": "postgres:*",
         "resource": "qcs::postgres:ap-shanghai:103xxx1481:DBInstanceId/postgres-0xxxx8e",
         "effect": "allow"
     }
 ]
}
2. Locate the created policy and click Bind User/Group in the "Operation" column.
3. In the pop-up window, select the user/group you want to authorize and click OK.
Policy for granting a user permissions to use all PostgreSQL resources
To grant a user permissions to use all PostgreSQL resources, you can associate the following policy with the user. The detailed steps are as follows:
1. Create a custom policy as instructed in Policy.
The example policy syntax is as follows. This example policy grants a user permissions to operate all PostgreSQL resources.
{
 "version": "2.0",
 "statement": [
     {
         "action": "postgres:*",
         "resource": "qcs::postgres:::*",
         "effect": "allow"
     }
 ]
}
2. Locate the created policy and click Bind User/Group in the "Operation" column.
3. In the pop-up window, select the user/group you want to authorize and click OK.
Policy for denying a user permissions to operate specific PostgreSQL instances
To deny a user permissions to operate specific PostgreSQL instances, you can associate the following policy with the user. The detailed steps are as follows:
1. Create a custom policy as instructed in Policy.
The example policy syntax is as follows. This example policy denies a user permissions to operate the PostgreSQL instances whose IDs are "postgres-c8xxxa4" and "postgres-d8xxxb4" respectively.
{
 "version": "2.0",
 "statement": [
     {
         "action": "postgres:*",
         "resource": [
                     "qcs::postgres::16xxx472:DBInstanceId/postgres-c8xxxa4",
                     "qcs::postgres::16xxx472:DBInstanceId/postgres-d8xxxb4",
                     ],
         "effect": "deny"
     }
 ]
}
2. Locate the created policy and click Bind User/Group in the "Operation" column.
3. In the pop-up window, select the user/group you want to authorize and click OK.
Custom policies
If preset policies do not meet your requirements, you can create custom policies as needed.
For detailed instructions, see Policy.
For more PostgreSQL-related policy syntax, see Access Policy Syntax.

Data Security

TDE Overview

Last updated：2024-12-04 12:53:23

Overview
Transparent Data Encryption (TDE) provides file-level encryption for data stored in the disk. It is imperceptible to applications at the upper layer of the database and doesn't require you to modify the business code. It encrypts data before it is written to disk and decrypts data when it is read from the disk in a transparent manner.
TDE is usually used to address security and compliance issues in various scenarios where the static data needs to be protected, such as PCI DSS and CCP compliance.
Encryption
In cryptography, encryption refers to converting information in plaintext into unreadable content in ciphertext.
Modern cryptography is a study based on number and probability theories. Its ultimate goal is the perfect security (also called information-theoretic security) defined by Claude Shannon.
Let E = (E, D) be a Shannon cipher defined over (K,M, C). Consider a probabilistic experiment in which the random variable k is uniformly distributed over K. If for all m0, m1 ∈ M, and all c ∈ C, we have
Pr[E(k, m0) = c] = Pr[E(k, m1) = c],
then we say that E is a perfectly secure Shannon cipher.
Simply put, ciphertext c can be encrypted from any plaintext m, and its relevance to the plaintext cannot be found in itself.
Encryption Algorithm Types
There are two types of encryption algorithms: symmetric and asymmetric.
Symmetric encryption: The same key is used for both encryption and decryption. It is much faster than asymmetric encryption and is required in many scenarios.
Asymmetric encryption: It is also called public-key cryptography. It uses different keys for encryption and decryption and is mainly used to transfer user information.
Common symmetric encryption algorithms include AES and 3DES. The most popular asymmetric encryption algorithm is RSA, whose reliability lies in the difficulty in factorizing extremely large integers.
TDE Threat Model
TDE is mainly used to protect static data (data at rest) to prevent data leakage caused by disk theft.
TencentDB for PostgreSQL Data Encryption Implementation
TencentDB for PostgreSQL applies to use the CMK stored in KMS to generate the DEK ciphertext and plaintext. Then, it uses them to encrypt and decrypt the keys used to encrypt Tencent Cloud product data.
﻿
This encryption scheme is called envelope encryption, where a key is used to encrypt another key. It has a high performance in encrypting and decrypting massive amounts of data. Specifically, it can generate DEKs to encrypt and decrypt local data, which guarantees the randomness and security of data keys based on KMS while meeting the requirements for robust business encryption.
As encryptions and decryptions are in-memory operations, the database will get key materials from KMS every time it is restarted or its memory is closed. No key materials used for decryption are stored in the local storage.
﻿
﻿

Enabling TDE

Last updated：2024-12-04 12:52:28

Overview
TencentDB for PostgreSQL comes with the transparent data encryption (TDE) feature. Transparent encryption means that the data encryption and decryption are transparent to users. TDE supports real-time I/O encryption and decryption of data files. It encrypts data before it is written to disk, and decrypts data when it is read into memory from disk, which meets the compliance requirements of static data encryption.
Prerequisites
TDE can be enabled only during instance creation and cannot be disabled once enabled.
Only the kernel version PostgreSQL v10.17_r1.2、v11.12_r1.2、v12.7_r1.2、v13.3_r1.2、v14.2_r1.0 supports TDE.
KMS must be activated. If it is not activated, you can purchase and activate it here.
To use TDE with a sub-account, you must create a service role for authorizing TencentDB for PostgreSQL to manipulate KMS. You can create a role here with your root account.
The sub-account must have the cam:PassRole, kms:GetServiceStatus, and kms:GetRegions permissions. If a permission is not granted, use the root account to grant it to the sub-account.
Note: 
The keys used for encryption are generated and managed by KMS. TencentDB for PostgreSQL does not provide keys or certificates required for encryption.
TDE does not incur fees, but KMS may. For more information, see Billing Overview.
If your account has overdue payment, you can't get keys from KMS, which may cause migration, upgrade, and other tasks to fail. For more information, see Notes on Arrears.
Notes
Once enabled, TDE cannot be disabled. If you revoke the key authorization, TDE will become unavailable after the database is restarted.
After TDE is enabled, data backups will also be encrypted, so even if a backup file is leaked, you don't need to worry about data leakage. To restore data from a backup, use the instance cloning feature of TencentDB for PostgreSQL.
TDE enhances the security of static data while compromising the read-write performance of encrypted databases. Therefore, use the feature based on your actual needs. Tests show that the average performance loss is around 2%–3%.
If the primary instance is associated with a read-only instance, TDE will be automatically enabled for and cannot be disabled by the read-only instance.
After TDE is enabled, your account balance must be greater than or equal to zero. Otherwise, instance migration may fail as KMS is inaccessible.
To avoid accidental instance deletion, Tencent Cloud supports key protection. If an instance is configured with data encryption, the key won't be immediately unbound after the instance is isolated and eliminated. The key cannot be deleted from KMS until three days after the instance is eliminated from the recycle bin.
Directions
1. Log in to the TencentDB for PostgreSQL purchase page and enable the database encryption feature in Enable Encryption.
2. In the pop-up window, select a key and click OK.
Note: 
An instance with TDE enabled cannot be restored from a physical backup to a self-created database on another server.
Once you enable TDE, you cannot disable it.
KMS Service: If KMS is not activated, you need to purchase it first.
KMS Key Authorization: If a message indicating that you are not authorized is displayed, you can click the authorization link to enter the role authorization page and authorize TencentDB for PostgreSQL to manipulate KMS with a service role.
Select Key:
Select the KMS region based on your instance region. If No KMS service in the region is displayed, KMS is unavailable in the selected region, and you cannot enable encryption.
If you select Use key auto-generated by Tencent Cloud, the key will be auto-generated by Tencent Cloud.
If you select Use existing custom key (BYOK), you can select a key created by yourself.
Note: 
If there are no custom keys, click Go to create to create keys in the KMS console. For more information, see Creating a Key.

SSL Encryption Settings

Last updated：2025-02-13 17:02:07

SSL Encryption Overview
Secure Sockets Layer (SSL) authentication is a process that authenticates the connection from the client to the cloud database server. It is performed for both the user and server. You can obtain a CA certificate after you enable SSL encryption and upload it to the server. When users access the database from the client, the SSL protocol will be activated to establish a secure channel between the client and the database server to realize encrypted data transmission. This prevents data interception, tampering, and eavesdropping during transmission and ensures data transmission security for both parties.
The SSL protocol is required to run over a reliable transport layer protocol (such as TCP). SSL is independent of application layer protocols, and high-layer application layer protocols (such as HTTP, FTP, and TELNET) can transparently run over the SSL protocol. The SSL protocol has completed data encryption, communication key negotiation, and server authentication before application layer protocols transmit data. In this way, the data transmitted by application layer protocols is encrypted, which ensures communication privacy.
Background
If encryption is not performed during database access, all data transmitted over the network is in plaintext. As a result, data may be eavesdropped, tampered with, and intercepted by users with malicious purposes. The SSL protocol is designed to address such risks. In theory, it has the following capabilities:
The information is encrypted and cannot be eavesdropped by third parties.
There is a verification mechanism. Once the information is tampered with, both the communicating parties will detect it promptly.
The identity certificate is equipped to prevent identity impersonation.
TencentDB for PostgreSQL supports enabling SSL encryption to enhance linkage security. It also supports downloading the SSL CA certificate and installing it on application services.
Note:
To ensure the traffic security between the database and the server, SSL encryption does not protect data. You can encrypt network connections at the transport layer to improve communication data security and integrity, but the response time of network connections will increase.
Must-Knows
The instance version is PostgreSQL 11 or later.
TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 are supported.
SSL encryption is not enabled by default for instances cloned from existing ones. You can enable it manually.
If you need to enable SSL encryption for a read-only instance, it is strongly recommended that you enable SSL encryption for all read-only instances in the read-only group. Otherwise, some requests may fail because the protected connection address is the VIP of the read-only group.
When you enable SSL encryption, your database instance will be restarted to load the SSL certificate. Make sure that your businesses are configured with a reconnection mechanism.
Enabling SSL Encryption
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to go to the Instance Management page.
2. Go to Data Security on the Instance Management page and click the SSL tab.
﻿
3. ﻿This feature is disabled by default. Click the switch and then click Confirm to enable SSL encryption.
The area for enabling SSL encryption is as follows:
﻿
﻿The system supports specifying a VIP or public network domain name as the protected connection address when you enable SSL encryption. If the instance has two VIPs, select one of the VIPs. Each time you enable SSL encryption, you can select only one VIP or public network domain name.
Click Download to download the SSL CA certificate, which is valid for 20 years. The downloaded package (Tencent-PG-SSL-CA.zip) contains the following three files:
.p7b file: It is used to import the CA certificate to Windows systems.
.jks file: It is a Java KeyStore/TrustStore file with the password set to tencentdb_pg and is used to import the CA certificate chain to Java programs.
.pem file: It is used to import the CA certificate to other operating systems or applications.
Connecting to a Database via SSL
Using psql for Connection via SSL
Note:
This method requires the command line tool psql of the local PostgreSQL client. Make sure that you have installed the PostgreSQL client. For details, see the PostgreSQL official documentation.
1. Create a .postgresql folder under the /usr/local/pgsql/ directory.
mkdir -p /usr/local/pgsql/.postgresql
2. Copy the downloaded server certificate ca.pem to the .postgresql folder.
[root@VM-0-6-tencentos .postgresql]# ll
total 4
-rw------- 1 postgres postgres 2681 Feb  6 11:13 ca.pem
3. Modify the permissions of the .postgresql folder.
chown postgres:postgres /usr/local/pgsql/.postgresql/*
chmod 600 /usr/local/pgsql/.postgresql/*
4. Set the environment variables for the postgres user.
[root@VM-0-6-tencentos .postgresql]# export PGSSLROOTCERT="/usr/local/pgsql/.postgresql/ca.pem"
[root@VM-0-6-tencentos .postgresql]# echo $PGSSLROOTCERT
/usr/local/pgsql/.postgresql/ca.pem
5. Set the authentication method for the client to connect to the database.
[root@VM-0-6-tencentos .postgresql]# export PGSSLMODE="require"
[root@VM-0-6-tencentos .postgresql]# echo $PGSSLMODE
require
Note:
For the description of the PGSSLMODE parameter, see the official documentation.
6. Connect to the database.
[root@VM-0-6-tencentos .postgresql]# psql -h10.6.0.20 -p5432 -Udbadmin -dpostgres
Password for user dbadmin: 
psql (16.4, server 11.22)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
﻿
postgres=> 
As shown above, if the output contains SSL connection, it indicates that the current connection uses SSL encryption.
Using JDBC for Connection via SSL
Note:
This method requires that you have installed the JDK and downloaded the JDBC driver.
1. Create a .postgresql folder under the /usr/local/pgsql/ directory.
mkdir -p /usr/local/pgsql/.postgresql
2. Copy the downloaded server certificate ca.pem to the .postgresql folder.
[root@VM-0-6-tencentos .postgresql]# ll
total 8
-rw------- 1 postgres postgres 2840 Feb  6 19:55 ca.jks
-rw------- 1 postgres postgres 2681 Feb  6 11:13 ca.pem
3. Modify the permissions of the .postgresql folder.
chown postgres:postgres /usr/local/pgsql/.postgresql/*
chmod 600 /usr/local/pgsql/.postgresql/*
4. Configure the business code to use SSL to connect to PostgreSQL and run the program.
The configuration example for the .pem certificate is as follows. Specific parameters are configured based on your business details.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
﻿
public class Main {
    public static void main(String[] args) {
        try {
            Class.forName("org.postgresql.Driver");
﻿
            Properties props = new Properties();
            props.setProperty("user", "dbadmin");
            props.setProperty("password", "xxxxxxxx");
            props.setProperty("ssl", "true");
            props.setProperty("sslmode", "verify-ca");
            props.setProperty("sslrootcert", "/usr/local/pgsql/.postgresql/ca.pem");
﻿
            Connection conn = DriverManager.getConnection(
                "jdbc:postgresql://10.6.0.10:5432/postgres",
                props
            );
﻿
            Statement stmt = conn.createStatement();
﻿
            ResultSet rs = stmt.executeQuery("SELECT * FROM mytable");
﻿
            while (rs.next()) {
                System.out.println(rs.getString("id"));
            }
﻿
            conn.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}
The configuration example for the .jks certificate is as follows. Specific parameters are configured based on your business details.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
﻿
public class Main1 {
    public static void main(String[] args) {
        try {
            Class.forName("org.postgresql.Driver");
﻿
            System.setProperty("javax.net.ssl.trustStore", "/usr/local/pgsql/.postgresql/ca.jks");
            System.setProperty("javax.net.ssl.trustStorePassword","tencentdb_pg");
            System.setProperty("javax.net.ssl.keyStore","/usr/local/pgsql/.postgresql/ca.jks");
            System.setProperty("javax.net.ssl.keyStorePassword","tencentdb_pg");
            Properties props = new Properties();
            props.setProperty("user", "dbadmin");
            props.setProperty("password", "xxxxx");
            props.setProperty("ssl", "true");
            props.setProperty("sslmode", "require");
            props.setProperty("sslfactory", "org.postgresql.ssl.DefaultJavaSSLFactory");
            Connection conn = DriverManager.getConnection(
                "jdbc:postgresql://10.6.0.10:5432/postgres",
                props
            );
﻿
            Statement stmt = conn.createStatement();
﻿
            ResultSet rs = stmt.executeQuery("SELECT * FROM mytable");
﻿
            while (rs.next()) {
                System.out.println(rs.getString("id"));
            }
﻿
            conn.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
Using Go for Connection via SSL
Note:
This method requires that you have installed Go and completed the driver configuration.
1. Create a .postgresql folder under the /usr/local/pgsql/ directory.
mkdir -p /usr/local/pgsql/.postgresql
2. Copy the downloaded server certificate ca.pem to the .postgresql folder.
[root@VM-0-6-tencentos .postgresql]# ll
total 4
-rw------- 1 postgres postgres 2681 Feb  6 11:13 ca.pem
3. Modify the permissions of the .postgresql folder.
chown postgres:postgres /usr/local/pgsql/.postgresql/*
chmod 600 /usr/local/pgsql/.postgresql/*
4. Configure the business code to use SSL to connect to PostgreSQL and run the program. The configuration example is as follows. Specific parameters are configured based on your business details.
package main
﻿
import (
	"database/sql"
	"fmt"
	"log"
﻿
	_ "github.com/lib/pq"
)
﻿
func main() {
	connStr := "user=dbadmin password=Lxh202405! dbname=postgres host=10.6.0.20 port=5432 sslmode=verify-full sslrootcert=/usr/local/pgsql/.postgresql/ca.pem"
	db, err := sql.Open("postgres", connStr)
	if err != nil {
		log.Fatal(err)
	}
﻿
	err = db.Ping()
	if err != nil {
		log.Fatal(err)
	}
﻿
	fmt.Println("Successfully connected!")
}
Refreshing the Server Certificate
If you want to change the VIP protected through SSL encryption in the following scenarios, you can refresh the server certificate.
Adding a network for an instance
A new VIP will be added after you add a network for an instance. If the instance has enabled SSL encryption and the selected protected address is the original VIP, an error is reported when you use the new VIP to connect to the instance from the client and enable SSL encryption. In this case, you need to refresh the server certificate and re-select a VIP you want to protect.
Deleting a network for an instance
The corresponding VIP will be deleted after you delete a network for an instance. If the instance has enabled SSL encryption and the selected protected address is the deleted VIP, an error is reported when you use the deleted VIP or other VIPs of the instance to connect to the instance from the client and enable SSL encryption. In this case, you need to refresh the server certificate and re-select a VIP you want to protect.
Enabling public network access for an instance
A public network connection address will be added after you enable public network access for an instance. If the instance has enabled SSL encryption but the selected protected address is not the public network address, an error is reported when you use the public network address to connect to the instance from the client and enable SSL encryption. In this case, you need to refresh the server certificate and select the public network address as the protected address.
Disabling public network access for an instance
The public network address will be reclaimed after you disable public network access for an instance. If the instance has enabled SSL encryption and the selected protected address is the public network address, an error is reported when you use the public network address to connect to the instance from the client and enable SSL encryption. In this case, you need to refresh the server certificate and select a VIP that you want to protect.
Adding read-only instances to a read-only group
All read-only instances in the read-only group have enabled SSL encryption, and a new read-only instance is added to the group. This instance has not enabled SSL encryption or has enabled SSL encryption but the selected protected address is not the VIP of the read-only group. As a result, some requests may fail when you use the VIP of the read-only group to connect to instances from the client. In this case, you need to enable SSL encryption for all read-only instances in the read-only group and select the VIP of the read-only group as the protected address.
Changing the protected address for a read-only instance
When you enable SSL encryption for a read-only instance, you can select the VIP of the read-only group or the read-only instance as the protected address. If you want to change the protected address, you need to refresh the server certificate.
The steps for refreshing the server certificate are as follows:
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to go to the Instance Management page.
2. Go to Data Security on the Instance Management page and click the SSL tab.
3. Check the current protected connection address on the SSL tab.
﻿
4. Click the Modify to modify the address.
﻿
Disabling SSL Encryption
Note:
When you disable SSL encryption, your database instance will be restarted to uninstall the SSL certificate. Make sure that your businesses are configured with a reconnection mechanism.
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click Instance ID or Manage in the Operation column to go to the Instance Management page.
2. Go to Data Security on the Instance Management page and click the SSL tab.
3. Click the switch and then click OK in the dialog box.
﻿

Tenant and Resource Isolation

Database Resource Isolation

Last updated：2025-03-11 14:29:44

Application Scenario
In some service scenarios, the database object database corresponds to related service logic. A typical example is the SaaS scenario where the database corresponds to the tenant. Therefore, it is necessary to address the issue of database resource isolation. This document mainly describes how to achieve CPU isolation for databases in TencentDB for PostgreSQL instances.
Setting Database Resource Isolation
Note:
Currently, only PostgreSQL 14 kernel versions of v14.11_r1.21 and later, PostgreSQL 15 kernel versions of v15.6_r1.10 and later, and PostgreSQL 16 kernel versions of v16.2_r1.3 and later support resource isolation capability. For details, refer to Kernel Version Release Note.
If you need to enable the database resource isolation mode, submit a ticket to contact us to enable the plug-in tencentdb_serverless and set relevant parameters.
The parameter tencentdb_serverless.min_cpu_cores is the minimum number of CPU cores that can be set for instances, and the parameter tencentdb_serverless.max_cpu_cores is the maximum number of CPU cores that can be set for instances. These two parameters are mainly used by the backend management system to control resource isolation of databases in instances. Users can view them but do not need to modify them.
All CPU resources are set to take effect immediately.
Currently, resource isolation for databases is only supported for primary instances.
﻿
Once you have enabled the tencentdb_serverless plugin and set the relevant plugin parameters tencentdb_serverless.min_cpu_cores and tencentdb_serverless.max_cpu_cores, you can start the configuration. You can use the following command to check that the plugin has been installed successfully:
postgres=> \dx;
                                             List of installed extensions
         Name          | Version |   Schema   |                              Description                               
-----------------------+---------+------------+------------------------------------------------------------------------
 pg_stat_log           | 1.0     | public     | track runtime execution statistics of all SQL statements executed
 pg_stat_statements    | 1.9     | public     | track planning and execution statistics of all SQL statements executed
 plpgsql               | 1.0     | pg_catalog | PL/pgSQL procedural language
 tencentdb_serverless  | 1.0     | public     | extension for serverless mode
 tencentdb_system_stat | 1.0     | public     | track execution statistics of querssy executed
(5 rows)
 The initial values of the tencentdb_serverless.min_cpu_cores and tencentdb_serverless.max_cpu_cores parameters are the current number of cores of the instance. These two parameters are mainly used for the back-end management system to control the resource isolation of the database within the instance, and users do not need to modify them. If the instance configuration changes later, the two parameters will change accordingly. You can check the current value of the parameters using the following command.
postgres=> show tencentdb_serverless.min_cpu_cores;
 tencentdb_serverless.min_cpu_cores 
------------------------------------
 8
(1 row)
﻿
postgres=> show tencentdb_serverless.max_cpu_cores;
 tencentdb_serverless.max_cpu_cores 
------------------------------------
 8
(1 row)
Note:
When there are multiple database objects in the instance, a CPU resource limit needs to be set for each database for the configuration to take effect.
After checking the plugin and parameters, you can start setting the upper and lower CPU resource limits for the database. We provide corresponding functions or views for you to call. Details are as follows:
Setting the CPU Resource Limits of the Specified Database
The function definition is as follows:
tencentdb_serverless.set_database_cpu_limit(database_name text [, min_cpu_cores numeric(5,1), max_cpu_cores numeric(5,1)]) 
Call example:
postgres=> select tencentdb_serverless.set_database_cpu_limit('tenant_001',2,2.5);
 set_database_cpu_limit 
------------------------
 
(1 row)
Clearing the CPU Resource Limits of the Specified Database
The function definition is as follows:
tencentdb_serverless.reset_database_limit(database_name text) 
Call example:
postgres=> select tencentdb_serverless.reset_database_limit('tenant_001');
 reset_database_limit 
----------------------
 
(1 row)
Clearing the CPU Resource Limits of All Databases in the Instance
The function definition is as follows:
tencentdb_serverless.reset_all_database_limit()
Call example:
postgres=> select tencentdb_serverless.reset_all_database_limit();
 reset_all_database_limit 
--------------------------
 
(1 row)
Viewing the Details of All Configured CPU Resource Limits in the Current Instance.
We offer the view tencentdb_serverless.resource_limit_view for you to view the details of all configured CPU resource limits in the current instance. The field definitions are as follows:
Column name
Meaning
database_name
The name of the database
min_cpu_cores
The minimum number of CPU cores that the current database can use
max_cpu_cores
The maximum number of CPU cores that the current database can use
min_mem_kilobytes
The maximum memory size that the current database can use, measured in kB. Reserved field, currently not in use.
max_mem_kilobytes
The maximum memory size that the current database can use, measured in kB. Reserved field, currently not in use.
Call example:
postgres=> select * from tencentdb_serverless.resource_limit_view;
 database_name | min_cpu_cores | max_cpu_cores | min_mem_kilobytes | max_mem_kilobytes 
---------------+---------------+---------------+-------------------+-------------------
 tenant_001    |           2.0 |           2.5 |                   |                  
 tenant_002    |           2.0 |           2.5 |                   |                  
(2 rows)
Process Monitoring
When all databases in an instance are configured with CPU resource isolation, if the overall resource utilization of the instance is high, each database can ensure the use of the minimum configured CPU cores. Additionally, if you need to check which databases are using more resources in the current system, you can use Process Monitoring capabilities. To view the CPU resource usage details of all databases, you can use the following statement:
postgres=> select datname,sum(cpu_usage) as cpu_usage from tencentdb_process_system_usage where datname !='NULL' group by datname;
  datname   | cpu_usage 
------------+-----------
 postgres   |         3
 tenant_001 |      1.99
 tenant_002 |         1
(3 rows)
When process monitoring finds that certain database resources have high utilization, you can adjust the CPU configuration of the database in real time. The configuration can take effect in real time.
Resource Migration
When a database corresponds to a tenant, and we discover through process monitoring that when the database's resource usage is consistently high and requires resource reintegration, TencentDB for PostgreSQL offers data migration capabilities. You can configure TencentDB for PostgreSQL's Logical Migration. The figure below shows how to configure a migration task:
﻿
Disabling Database Resource Isolation
If you need to disable the database's CPU resource isolation mode, submit a ticket to contact us for data cleanup. After receiving the ticket, the back-end engineer will reset all of the CPU resource parameters tencentdb_serverless.min_cpu_cores and tencentdb_serverless.max_cpu_cores, remove all resource configurations, and finally delete the plugin tencentdb_serverless.

Security Groups

Managing Security Groups

Last updated：2024-12-04 12:50:48

Overview
A security group is a stateful virtual firewall capable of filtering. As an important means for network security isolation provided by Tencent Cloud, it can be used to set network access controls for one or more TencentDB instances. Instances with the same network security isolation demands in one region can be put into the same security group, which is a logical group. TencentDB and CVM share the security group list and are matched with each other within the security group based on rules. For specific rules and limitations, please see Security Group Overview.
Note: 
TencentDB for PostgreSQL security groups currently only support network access control for VPCs and public networks but not the classic network.
Security groups that currently support public network access are available only in the Beijing, Shanghai, Guangzhou, and Chengdu regions.
As TencentDB does not have active outbound traffic, outbound rules are not applicable to TencentDB.
TencentDB for PostgreSQL primary instances, read-only instances, and read-only instance groups (RO groups) support security groups.
Configuring Security Groups
Step 1. Create a security group
1. Log in to the CVM console.
2. Select Security Group on the left sidebar, select a region, and click New.
3. In the pop-up dialog box, configure the following items and click OK.
Template: select a template based on the service to be deployed on the TencentDB instance in the security group, which simplifies the security group rule configuration, as shown below:
Template
Description
Remarks
Open all ports
All ports are open. May present security issues.
-
Open ports 22, 80, 443, and 3389 and the ICMP protocol
Ports 22, 80, 443, and 3389 and the ICMP protocol are opened to the internet. All ports are opened to the private network.
This template does not take effect for TencentDB.
Custom
You can create a security group and then add custom rules. For detailed directions, please see "Step 2. Add a security group rule" below.
The custom template is recommended.
Name: name of the security group.
Project: by default, DEFAULT PROJECT is selected. Select a project for easier management.
Notes: a short description of the security group for easier management.
Step 2. Add a security group rule
1. On the Security Group page, click Modify Rule in the Operation column on the row of the security group for which to configure a rule.
2. On the security group rule page, click Inbound rule > Add Rule.
3. In the pop-up dialog box, set the rule.
Type: Custom by default.
Source or Target: traffic source (inbound rules) or target (outbound rules). You need to specify one of the following options:
Source or Target
Description
A single IPv4 address or an IPv4 range
In CIDR notation, such as 203.0.113.0, 203.0.113.0/24 or 0.0.0.0/0, where 0.0.0.0/0 indicates all IPv4 addresses will be matched.
A single IPv6 address or an IPv6 range
In CIDR notation, such as FF05::B5, FF05:B5::/60, ::/0 or 0::0/0, where ::/0 or 0::0/0 indicates all IPv6 addresses will be matched.
ID of referenced security group. You can reference the ID of:
Current security group
Other security group
﻿
To reference the current security group, please enter the ID of security group associated with the CVM.
You can also reference another security group in the same region and belongs to the same project by entering the security group ID.
﻿
Reference an IP address object or IP address group object in a parameter template.
-
Protocol Port: enter the protocol type and port range or reference a protocol/port or protocol/port group in a parameter template.
Note: 
To connect to TencentDB for PostgreSQL, port 5432 must be opened.
Policy: Allow or Reject. Allow is selected by default.
Allow: traffic to this port is allowed.
Reject: data packets will be discarded without any response.
Notes: a short description of the rule for easier management.
4. Click Complete.
Use cases
Scenario: you have created a TencentDB for PostgreSQL instance and want to access it from a CVM instance.
Solution: add an inbound security group rule where TCP:5432 is opened.
You can also set Source to all or specific IPs (IP ranges) as needed to allow them to access TencentDB for PostgreSQL from a CVM instance.
Inbound or Outbound
Type
Source
Protocol and Port
Policy
Inbound
Custom
All IPs: 0.0.0.0/0 
Specific IPs: specify IPs or IP ranges
TCP:5432
Allow
Importing Security Group Rules
1. On the Security Group page, click the ID/name of the desired security group.
2. On the inbound rule or outbound rule tab, click Import Rule.
3. In the pop-up dialog box, select an edited inbound/outbound rule template file and click Import.
Note: 
 As existing rules will be overwritten after importing, we recommend that you export the existing rules before importing new ones.
Cloning Security Groups
1. On the Security Group page, locate the desired security group and click More > Clone in the Operation column.
2. In the pop-up dialog box, select the target region and target project, enter the new security group name, and click OK. If the new security group needs to be associated with a CVM instance, do so by managing the CVM instances in the security group.
Deleting Security Groups
1. On the Security Group page, locate the security group to be deleted and click More > Delete in the Operation column.
2. Click OK in the pop-up dialog box. If the current security group is associated with a CVM instance, it must be disassociated before it can be deleted.

Associating Instances with Security Groups

Last updated：2024-12-04 12:51:31

A security group is an instance-level firewall provided by Tencent Cloud for controlling inbound traffic of TencentDB. You can associate a security group with an instance when purchasing it or later in the console.
In TencentDB for PostgreSQL, primary instances, read-only instances, and read-only instance groups (RO groups) can use security groups which are independent from each other.
Note: 
A TencentDB for PostgreSQL instance can associate with up to five security groups.
The security group of an RO group controls the access address of the RO group itself rather than the access addresses of the read-only instances in this RO group. For example, if the access from an IP is allowed by the security group of an RO group but denied by that of a read-only instance in the RO group, this IP can still access to the read-only instance using the access address of the RO group instead of the access address of the read-only instance.
Prerequisites
You have created security groups for TencentDB instances in the security group console. For more information, please see Managing Security Groups.
Associating Security Groups with Primary/Read-Only Instances
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click the ID of the instance to be associated and enter the instance management page.
2. On the Security Group page, click Configure Security Group.
3. In the pop-up dialog box, select the security group to be associated and click OK. 
﻿
Associating Security Groups with RO Groups
1. Log in to the TencentDB for PostgreSQL console. In the instance list, click the ID of a read-only instance in the desired RO group and enter the instance management page.
2. On the Security Group page, select RO Group for Object Type in the Security Group Object section and click Configure Security Group in the Associated Security Group section.
3. In the pop-up dialog box, select the security group to be associated and click OK.
Adjusting the Priorities of Security Groups
You can associate up to five security groups with a TencentDB instance. If you have associated multiple security groups, these security groups are executed based on their priorities. You can adjust the priorities as follows.
1. Log in to the TencentDB for PostgreSQL console, click an instance ID in the instance list, and enter the instance management page.
2. Select the Security Group page.
3. In the Associated Security Group section, click Edit, and click the Move up or Move down icon in the Operation column to adjust the priorities. A security group ranking higher in the list has a higher priority. Configurations of all the security groups are connected by OR. If the configurations of two security groups conflict, whichever has a higher priority will prevail.
4. After adjusting the priority, click Save.

Monitoring and Alarms

Monitoring Feature

Last updated：2025-09-10 22:19:27

Monitoring in Console
To make it easier for you to view and stay up to date with how instances work, TencentDB for PostgreSQL provides a wide variety of performance monitoring metrics. You can log in to the TencentDB for PostgreSQL console and view them on the System Monitoring tab on the corresponding instance management page.
Monitoring metrics
Metric Name
Monitoring Metric Name
Unit
Metric Type
CPU utilization
cpu
%
Actual CPU utilization
used storage space
storage
GB
Instance space size
Memory Usage
memory
MBytes
Actual memory usage.
Memory usage
memory_rate
%
Actual memory utilization
QPS
qps
Times/second
Number of executed SQL statements per second.
Number of Connections
connections
Counts
Number of database connections during collection.
Number of requests
read_write_calls
Times
Number of read/write requests in a statistical period.
Number of read requests
read_calls
Times
Number of read requests in a statistical period.
Number of write requests
write_calls
Times
Number of write requests in a statistical period.
Other Requests
other_calls
Times
Number of other requests in a statistical period (requests other than SELECT, INSERT, UPDATE, DELETE).
Buffer cache hit rate
hit_percent
%
Hit rate of all SQL statements executed in a statistical period
Average execution latency
sql_runtime_avg
ms
Average execution latency of all SQL statements in one statistical period.
Longest TOP10 Execution Latency
sql_runtime_max
ms
Longest TOP10 average execution latency of SQL statements in a statistical period.
Shortest TOP10 Execution Latency
sql_runtime_min
ms
Shortest TOP10 average execution latency of SQL statements in a statistical period.
The number of remaining XIDs
remain_xid
Counts
During database collection, display the remaining xid count of the database with the least xid. No such metric for read-only instances.
Standby log shipping and playback position difference
xlog_diff
Byte
The size difference between logs sent from the primary database to the standby and replay completed reflects the speed of log application on the standby. This metric can help evaluate standby performance and network transmission speed. No such metric for read-only instances.
Storage Usage
storage_rate
%
Total storage utilization, including temporary files, data files, log files, and other database files.
Number of Slow Queries
slow_query_cnt
Counts
The number of slow queries in a collection cycle.
log write delay
xlog_diff
Byte
The size difference between logs sent from the primary database to the standby and replay completed reflects the speed of log application on the standby. This metric can help evaluate standby performance and network transmission speed. No such metric for read-only instances.
log write time delay
xlog_diff_time
Seconds
The time difference between logs sent from the primary database to the standby and logs received and written to disk. No such metric for read-only instances, and this metric is only available for instance versions 10.x or later.
Primary-standby data synchronization delay
slave_apply_delay
Byte
The size difference between standby database replay LSN and current LSN of primary instance. For the primary instance, this metric reflects the RTO for fault switch. For read-only instances, it reflects data latency.
Primary-standby data sync delay time
replay_lag
Seconds
The delay time of data sync between the primary and replica databases. A shorter delay means the primary-replica data is more consistent. During primary database failure, less data is lost after the switch.
Number of Active Connections
active_conns
Counts
Trigger database collection during instantaneous active connections (non-idle connection).
Number of idle connections
idle_conns
Counts
Query instantaneous idle connections in the database during collection.
Number of SQL statements with execution duration exceeding 1 second
long_query
Counts
Number of SQL statements being executed with execution time exceeding 1 second during database collection.
Number of transactions with execution duration exceeding 1 second
long_xact
Counts
Number of transactions with execution time exceeding 1 second during database collection.
Number of idle transactions
idle_in_xact
Counts
Number of transactions in idle in transaction state when triggering database collection.
Number of idle transactions exceeding 5 seconds
long_idle_in_xact
Counts
Number of transactions in idle in transaction state exceeding 5 seconds during database collection.
Number of waiting sessions
waiting
Counts
Number of database connections in a waiting state.
Number of sessions waiting exceeding 5 seconds
long_waiting
Counts
The number of database connections with a waiting time exceeding 5 seconds.
Number of 2PC transactions
2PC
Counts
Number of 2PC transactions during database collection.
Number of 2PC transactions unsubmitted for over 5 seconds
long_2pc
Counts
Number of 2PC transactions with execution time exceeding 5 seconds during database collection.
Number of new connections within 5 seconds
new_conn_in5s
Counts
Query all connection counts established within the last 5 seconds when triggering database collection.
TPS
tps
Times/second
Number of successful transactions per second (including rollbacks and submissions).
Number of transaction commits
xact_commit
Times/second
Average transactions per second in a statistical period.
Transaction rollback count
xact_rollback
Times/second
The average number of rolled-back transactions per second in a statistical period.
Number of record deletions per second
tup_deleted
Counts
Average number of tuples deletions per second in a statistical period. No Such Metric for read-only instances.
Number of insertions per second
tup_inserted
Counts
Average number of tuples insertions per second in a statistical period. No Such Metric for read-only instances.
Number of record updates per second
tup_updated
Counts
Average number of tuples updates per second in a statistical period. No Such Metric for read-only instances.
Number of index scan records per second
tup_fetched
Counts
Average number of index scan tuples per second in a statistical period.
Number of full-table scan records per second
tup_returned
Counts
The number of full-table scan tuples per second in a statistical period.
Number of deadlocks
deadlocks
Counts
Number of deadlocks in a statistical period.
log file size
log_file_size
GB
WAL log file occupied space size.
Size of data files
data_file_size
GB
Data file occupied space size.
Temporary file size
temp_file_size
MB
Temporary file size.
throughput rate
throughput
KBytes/s
Disk read/write speed per instance per second.
Read Throughput
throughput_read
KBytes/s
Instance disk read speed per second.
Write Throughput
throughput_write
KBytes/s
Disk write speed per instance per second.
connection utilization
conn_utilization
%
Current number of instance connections/Maximum number of connections.
instance port inbound traffic
cluster_in_flow
KBytes/s
Inbound traffic on the database instance listening port.
instance port outbound traffic
cluster_out_flow
KBytes/s
Outbound traffic on the database instance listening port.

Alarming Feature

Last updated：2024-01-24 11:20:59

Overview
You can create alarm policies to trigger alarms and send alarm notifications when the TencentDB instance status changes. The created alarm policies can determine whether an alarm needs to be triggered according to the difference between the monitoring metric value and the given threshold at intervals.
You can take appropriate precautionary or remedial measures in a timely manner when the alarm is triggered by changed product status. Therefore, properly created alarm policies can help you improve the robustness and reliability of your applications. For more information on alarms, see Creating Alarm Policy in Cloud Monitor.
To send an alarm for a specific status of a product, you need to create an alarm policy at first. An alarm policy is composed of three compulsory components, that is, the name, type and alarm triggering conditions. Each alarm policy is a set of alarm triggering conditions with the logical relationship "or", that is, as long as one of the conditions is met, an alarm will be triggered. The alarm will be sent to all users associated with the alarm policy. Upon receiving the alarm, the user can view the alarm and take appropriate actions in time.
Note: 
Make sure that you have set the default alarm recipient; otherwise, the default alarm policy of TencentDB won't be able to send notifications.
Directions
Creating an alarm policy
1. Log in to the Cloud Monitor console and select Alarm Configuration > Alarm Policy on the left sidebar.
2. In the alarm policy list, click Create.
3. On the Create Alarm Policy page, set the policy name, policy type, alarm object, and trigger condition.
An alarm trigger is a semantic condition composed of metric, comparison, threshold, statistical period, and duration. For example, if the metric is disk utilization, the comparison is >, the threshold is 80%, the statistical period is 5 minutes, and the duration is two statistical periods, then the data on disk utilization of a database will be collected once every five minutes, and an alarm will be triggered if the disk utilization exceeds 80% for two consecutive times.
The object instance to be associated with can be found by selecting the region where the object is located or searching for the instance ID of the object.
4. After confirming everything is correct, click Complete.
Associating alarm objects
After the alarm policy is created, you can associate alarm objects with it. When an alarm object satisfies an alarm trigger condition, an alarm notification will be sent.
1. In the alarm policy list, click the name of an alarm policy to enter the alarm policy management page.
2. Click Add Object in the Alarm Object section.
﻿
3. In the pop-up dialog box, select the alarm objects to be associated with, and click OK.

Overview

Last updated：2024-01-24 11:20:59

Introduction
Tags are key-value pairs provided by Tencent Cloud to easily identify resource. For more information, please see Product Overview.
You can use tags to categorize and manage TencentDB for PostgreSQL resources by various metrics such as business, purpose, and owner. You can also quickly locate a resource by its tag. In Tencent Cloud, the tag key-value pairs have no semantic meaning and are strictly parsed and matched as strings. To use tags, please pay attention to use limits first.
Here we describe a use case to show how a tag is used.
Use Case Background
A company has three PostgreSQL instances in Tencent Cloud. Those instances are distributed in three gaming businesses whose OPS owners are John, Jane, and Harry.
Configuring Tags
To manage the resources better, the company categorizes its TencentDB for PostgreSQL resources with tags and defines the following tag key-value pairs.
Tag Key
Tag Value
Business
Game 1, game 2, and game 3
OPS owner
John, Jane, and Harry
These tag key-value pairs are bound to TencentDB for PostgreSQL instances in the following way:
instance-id
Business
OPS Owner
postgres-abcdef1
Game 1
Harry
postgres-abcdef2
Game 2
Jane
postgres-abcdef3
Game 3
John
Using Tags
For more information on how to create and delete a tag, please see Querying Resources by Tag.
For more information on how to edit a tag in TencentDB for PostgreSQL, please see Editing a Tag.

Editing Tag

Last updated：2025-09-10 22:15:38

You can edit resource tags by the following steps.
Editing the Tag of a Single Instance
1. Log in to the TencentDB for PostgreSQL Console, locate the desired instance in the instance list, and click More > Edit Tag in the Operation column.
﻿
2. In the pop-up dialog box, add, modify, or delete a tag, and click OK.
﻿
Editing the Tags of Multiple Instances
1. Log in to the TencentDB for PostgreSQL Console, select desired instances in the instance list, and click More > Edit Tag at the top.
﻿
2. In the pop-up dialog box, add, modify, or delete tags, and click OK.

Information	Description
Data Replication Mode	For the data synchronization mode between the master and the slave, the current two-machine high availability (one master and one slave) architecture supports Async ( Asynchronous replication )and Semi-Sync ( Semi-synchronous replication ).
Instance Status	Display the current accessibility status of the instance. When the status is normal, normally receive user requests. If an abnormal display occurs, it indicates that the instance currently cannot receive application requests.
Instance Status
Failover Condition	When the Master node fails and cannot be recovered, automatic failover is required, with the Slave providing services. At this point, the system defines the failover conditions, which are the size and time of primary-backup latency. The default system conditions are less than or equal to 10240 MB and 10 seconds. For specific switch conditions, refer to Failover Description.
Primary AZ	It refers to the availability zone of the master node.
Standby AZ	It refers to the availability zone of the slave node.

Metric Name	Metric Description
Slave Log Write-to-Disk Latency (Bytes)	It refers to the difference in size between the slave log write-to-disk LSN and the current LSN of the master instance. For the master instance, this metric reflects the data loss size in the event of a failover.
Slave Log Write-to-Disk Time Latency (Seconds)	The time difference between the transmission of logs from the primary database to the secondary database and the reception and persistence of these logs on the secondary database reflects the potential data loss during failover for the primary instance. This metric is available only for instance versions 10.x and above.
Master-Slave Data Synchronization Latency (Bytes)	It refers to the difference in size between the slave replay LSN and the current LSN of the master instance. For the master instance, this metric reflects the RTO in the event of a failover. For read-only instances, this metric reflects the data latency size.
Master-Slave Data Synchronization Latency Time (Seconds)	The time difference between the transmission of logs from the primary database to the secondary database and the reception and replay of these logs by the secondary database. This metric is available only for instance versions 10.x and above.
Slave Log Send and Replay Position Difference (Bytes)	It refers to the size difference between the master instance sending the log to the slave instance and the completion of slave log replication. It reflects the speed of slave log application. You can mainly check the performance of the slave instance and the speed of network transmission through this metric. This metric is not available for read-only instances.

Task Type	Input	Output
Adjusting instance configuration	{ "Cpu":"2 core"//CPU configuration before instance adjustment. "Memory":"4 GiB"//Memory configuration before instance adjustment. "Storage":"10 GB"//Storage space configuration before instance adjustment. }	{ "Cpu":"2 core"//CPU configuration after instance adjustment. "Memory":"4 GiB"//Memory configuration after instance adjustment. "Storage":"20 GB"//Storage space configuration after instance adjustment. "Message":"success"//Specific returned result of the task. Success indicates success. For other statuses, see the specific information. }
Changing the read-only group for a read-only instance	{ "NewROGroupId":"pgrogrp-3p21ssox"//Target read-only group ID. "OldROGroupId":"pgrogrp-dct9wsml"//Source read-only group ID. "ROInstanceId":"pgro-a9qea3c9"//Read-only instance ID. }	{ "NewROGroup":{//Target read-only group details. "ROGroupId":"pgrogrp-3p21ssox" "ROGroupIp":"10.0.0.2" "ROGroupName":"1" "ROGroupPort":5432 } "OldROGroup":{//Source read-only group details. "ROGroupId":"pgrogrp-dct9wsml" "ROGroupIp":"10.0.0.6" "ROGroupName":"2" "ROGroupPort":5432 } "ROInstance":{//Read-only instance details. "ROInstanceId":"pgro-a9qea3c9" "ROInstanceIp":[ 0:"10.0.0.17" ] "ROInstanceName":"Unnamed" "ROInstancePort":5432 } }
Adding a read-only instance to a read-only group	{ "ReadOnlyGroupId":"pgrogrp-3p21ssox"//Target read-only group ID. "ReadOnlyInstanceId":"pgro-82nkylkb"//Read-only instance ID. }	{ "ROGroup":{//Target read-only group details. "ROGroupId":"pgrogrp-3p21ssox" "ROGroupIp":"10.0.0.2" "ROGroupName":"1" "ROGroupPort":5432 } "ROInstance":{//Read-only instance details. "ROInstanceId":"pgro-82nkylkb" "ROInstanceIp":[ 0:"10.0.0.10" ] "ROInstanceName":"Unnamed" "ROInstancePort":5432 } }
Removing a read-only instance from a read-only group	{ "ROGroupId":"pgrogrp-3p21ssox"//Source read-only group details. "ROInstanceId":"pgro-a9qea3c9"//Read-only instance ID. }	{ "ROGroup":{//Source read-only group details. "ROGroupId":"pgrogrp-3p21ssox" "ROGroupIp":"10.0.0.2" "ROGroupName":"1" "ROGroupPort":5432 } "ROInstance":{//Read-only instance details. "ROInstanceId":"pgro-a9qea3c9" "ROInstanceIp":[ 0:"10.0.0.17" ] "ROInstanceName":"Unnamed" "ROInstancePort":5432 } }
Adding a network	{ "DBInstanceId":"postgres-6s1kuw28"//Instance ID. "IsAssignVip":false//Whether the assigned VIP is registered. All are false here. "SubnetId":"subnet-piadji8r"//Subnet ID. "Vip":""//The VIP that is about to be assigned. All are empty here. "VpcId":"vpc-fz41fhgo"//Virtual Private Cloud (VPC) ID. }	{ "DBInstanceId":"postgres-6s1kuw28"//Instance ID. "DBInstanceNetInfo":{//Details of the newly added network. "Address":"" "Ip":"10.0.10.15" "Port":5432 "Status":"opened" "NetType":"private" "VpcId":"vpc-fz41fhgo" "SubnetId":"subnet-piadji8r" "ProtocolType":"postgresql" } }
Deleting a network	{ "DBInstanceId":"postgres-6s1kuw28"//Instance ID. "SubnetId":"subnet-piadji8r"//Subnet ID. "Vip":"10.0.10.15"//VIP to be deleted. "VpcId":"vpc-fz41fhgo"//Virtual Private Cloud (VPC) ID. }	{ "DBInstanceId":"postgres-6s1kuw28"//Instance ID. "DBInstanceNetInfo":{//Details of the deleted network. "Address":"" "Ip":"10.0.10.15" "Port":5432 "Status":"closed" "NetType":"private" "VpcId":"vpc-fz41fhgo" "SubnetId":"subnet-piadji8r" "ProtocolType":"postgresql" } }
Parameter configuration	{ "Name":"max_connections"//Modify the parameter name. "ExpectedValue":"2040"//Modify the parameter target value. }	{ "max_connections":{//Parameter name. "message":"this parameter must be modified on the master node first and reboot"//Prompt information for reference. "modify_after_value":"2040"//Target value of the parameter. "modify_before_value":"2048"//Original value of the parameter. "status":"success"//Modification status. } }

Upgrade Time	Description
Upgrade plugins before completing the major version upgrade.	Under this method, you need to check the plugin list of all databases and upgrade the plugins to the corresponding versions. The execution time is positively correlated with the number of databases and the number of plugins, which will extend the execution time of the entire major version upgrade. Please assess and then select.
Upgrade plugins after completing the major version upgrade.	Under this method, the database will promptly resume read and write operations upon the completion of the major version upgrade, during which the plugins will undergo updates. However, during the plugin update period, the plugin features may become unavailable. When selecting this upgrade time, you need to evaluate whether your business will be affected.
Do not upgrade the plugin version	Under this method, the database will promptly resume read and write operations upon completion of the major version upgrade, without automatically upgrading plugins. If needed, you can manually upgrade the plugins. When selecting this upgrade time, you need to evaluate whether your business will be affected.

Option	Description
Yes	Default option. Backup will incur fees. For details, reference Backup Space Billing. Users can choose to delete it after upgrade verification is completed. The deletion policy for this backup file is also managed by the user-configured backup retention rules. If you want to extend the backup set retention time, enter the backup recovery interface and click in the backup expiration time column to proceed with editing.
No	Select this option when the instance has backups that can be restored to the pre-upgrade state. Otherwise, it is not recommended.

Option	Description
Check without initiating task	Only perform pre-upgrade checks, including instance running status, legitimacy of instance parameter settings, database connection check, etc., but do not initiate the task. Users can use this operation to pre-check the feasibility of the upgrade.
Check and initiate task	Perform pre-upgrade checks, including instance running status, legitimacy of instance parameter settings, and database connection check. If the check passes, directly initiate the task.

Scaling Type	Event Metric	Description
Automatic scaling	ExpandCpuSucceeded	CPU elastic scale-out succeeded.
		ExpandCpuFailed	CPU elastic scale-out failed.
		ContractCpuSucceeded	CPU elastic scale-in succeeded.
Custom scaling	ExpandCpuSucceeded	CPU elastic scale-out succeeded.
		ExpandCpuFailed	CPU elastic scale-out failed.
		ContractCpuSucceeded	CPU elastic scale-in succeeded.

Parameter	Description
Scale-Out Method	Automatic scale-out and custom scale-out are supported. Select automatic scale-out here. Automatic scale-out: Perform a quick elastic scale-out operation based on performance to adapt to traffic peaks, and perform scale-in when traffic drops. Custom scale-out: Perform scale-out during a custom time period or cycle, and automatically perform CPU scale-in during other periods.
Number of cores for Scale-Out	The default value is consistent with the number of CPU cores of the current instance specification. For example, if the current instance specification is 2 cores and 4 GiB of memory, the number of cores for scale-out will also be 2 cores. After scale-out is successfully triggered, the CPU of the instance will be 4 cores.
Scale-Out Rule	Set the observation period and threshold for triggering scale-out. Observation period: Supported options are 1 minute, 3 minutes, 5 minutes, 10 minutes, 15 minutes, and 30 minutes. Threshold: Supported options include 40%, 50%, 60%, 70%, 80%, and 90%. The system will automatically monitor the CPU utilization metrics during the observation period. When the set threshold is reached, a CPU scale-out operation will be initiated.
Scale-In Rule	Set the observation period and threshold for triggering scale-in. Observation period: Supported options include 5 minutes, 10 minutes, 15 minutes, and 30 minutes. Threshold: Supported options include 10%, 20%, and 30%. The system will automatically monitor the CPU utilization metrics during the observation period. When the set threshold is reached, a CPU scale-in operation will be initiated.

Specification	Weight
2 GB memory	1
4 GB memory	2
8 GB memory	2
12 GB memory	4
16 GB memory	4
24 GB memory	8
32 GB memory	8
48 GB memory	10
64 GB memory	12
96 GB memory	14
128 GB memory	16
240 GB memory	26
480 GB memory	50

Role	Allowed Access
pg_execute_server_program	Allow executing programs on the database server as the user the database runs as with COPY and other functions which allow executing a server-side program.
pg_monitor	Read/Execute various monitoring views and functions. This role is a member of pg_read_all_settings, pg_read_all_stats, and pg_stat_scan_tables.
pg_read_all_settings	Read all configuration variables, even those normally visible only to superusers.
pg_read_all_stats	Read all pg_stat_* views and use various statistics related extensions, even those normally visible only to superusers.
pg_read_server_files	Allow reading files from any location the database can access on the server with COPY and other file-access functions.
pg_signal_backend	Signal another backend to cancel a query or terminate its session.
pg_stat_scan_tables	Execute monitoring functions that may take ACCESS SHARE locks on tables, potentially for a long time.
pg_write_server_files	Allow writing to files in any location the database can access on the server with COPY and other file-access functions.
public	An implicitly defined group that always includes all roles. Any particular role will have the sum of permissions granted directly to public. PostgreSQL grants default permissions on some types of objects to public.

Permissions	Abbreviation	Supported Object
SELECT	r ("read")	LARGE OBJECT, SEQUENCE, TABLE (and table-like objects), table column
INSERT	a ("append")	TABLE, table column
UPDATE	w ("write")	LARGE OBJECT, SEQUENCE, TABLE, table column
DELETE	d	TABLE
TRUNCATE	D	TABLE
REFERENCES	x	TABLE, table column
TRIGGER	t	TABLE
CREATE	C	DATABASE, SCHEMA, TABLESPACE
CONNECT	c	DATABASE
TEMPORARY	T	DATABASE
EXECUTE	X	FUNCTION, PROCEDURE
USAGE	U	DOMAIN, FOREIGN DATA WRAPPER, FOREIGN SERVER, LANGUAGE, SCHEMA, SEQUENCE, TYPE

Object Type	Permissions	Permissions of Default Role (public)	psql Command to Query Permissions
DATABASE	CTc	Tc	\l
DOMAIN	U	U	\dD+
FUNCTION or PROCEDURE	X	X	\df+
FOREIGN DATA WRAPPER	U	none	\dew+
FOREIGN SERVER	U	none	\des+
LANGUAGE	U	U	\dL+
LARGE OBJECT	rw	none	-
SCHEMA	UC	none	\dn+
SEQUENCE	rwU	none	\dp
TABLE (and table-like objects)	arwdDxt	none	\dp
Table column	arwx	none	\dp
TABLESPACE	C	none	\db+
TYPE	U	U	\dT+

Permission	Description
CREATEDB	Create a database.
BYPASSRLS	Bypass all row-level security policy checks.
REPLICATION	Have the REPLICATION permission by default, and allow granting the REPLICATION permission to other users.
CREATEROLE	Have the same CREATEROLE permission as the community edition, except that the role cannot create the pg_read_server_files, pg_write_server_files, and pg_execute_server_program roles.

Object	Description
database	By default, have the permissions of all databases not owned by a a superuser.
schema	By default, have the permissions of all schemas not owned by a superuser.
table/sequence	By default, have the permissions of all tables/sequences not owned by a a superuser.
function	By default, have the permissions of all functions not owned by a superuser.
language	No permissions.
tablespace	No permissions.
FDW/foreign server	By default, have the permissions of all FDWs/foreign servers not owned by a a superuser.
TYPE	By default, have the permissions of all TYPEs not owned by a superuser.

Object Type	Default PUBLIC Permission
Databases	CONNECT,TEMPORARY
Functions/Procedures	EXECUTE
Languages	USAGE
Data Types	USAGE

Specification\Parameter	max_replication_slots	max_wal_senders	max_worker_processes	max_logical_replication_workers	max_parallel_workers	max_connections
1C2GiB	[10-100]	[27-150]	[4-300]	[4-150]	[8-8]	[100-2048]
2C4GiB	[10-100]	[27-150]	[4-300]	[4-150]	[8-8]	[100-2048]
2C6GiB	[10-150]	[27-200]	[4-400]	[4-200]	[8-8]	[100-2048]
4C8GiB	[10-150]	[27-200]	[4-400]	[4-200]	[8-8]	[100-2048]
4C16GiB	[10-150]	[27-200]	[4-400]	[4-200]	[8-8]	[100-2048]
6C24GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-12]	[100-2048]
8C16GiB	[10-150]	[27-200]	[4-400]	[4-200]	[8-8]	[100-2048]
8C32GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-16]	[100-4000]
8C48GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-16]	[100-4500]
8C64GiB	[10-400]	[27-450]	[4-900]	[4-450]	[8-24]	[100-5500]
12C24GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-12]	[100-2048]
12C64GiB	[10-400]	[27-450]	[4-900]	[4-450]	[8-24]	[100-5500]
16C32GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-16]	[100-4000]
16C96GiB	[10-400]	[27-450]	[4-900]	[4-450]	[8-32]	[100-8000]
20C128GiB	[10-500]	[27-450]	[4-900]	[4-450]	[8-40]	[100-10000]
24C48GiB	[10-200]	[27-250]	[4-500]	[4-250]	[8-16]	[100-4500]
24C192GiB	[10-500]	[27-550]	[4-1200]	[4-550]	[8-50]	[100-12000]
28C240GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-13000]
32C64GiB	[10-400]	[27-450]	[4-900]	[4-450]	[8-24]	[100-5500]
48C480GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-22000]
64C256GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-13000]
64C384GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-20000]
64C512GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-22000]
90C720GiB	[10-600]	[27-650]	[4-1300]	[4-650]	[8-60]	[100-36000]

Instance Type	Instance Configuration	Maximum max_connections Value
Primary instance	8 CPU cores and 48 GB memory with 100 GB disk	4500
Read-only instance	1 CPU core and 2 GB memory with 100 GB disk	2048
Read-only instance	1 CPU core and 2 GB memory with 100 GB disk	2048

Parameter Value	Description
postgresql_%a_%H.log	Selecting this value will keep logs for 7 days.
postgresql_%d_%H.log	Selecting this value allows logs to be retained for 30 days, which is the system default.

Field value.	Type	Description
Timestamp	-	A reserved field for CLS, which represents the log generation time.
InstanceId	String	Database instance ID, such as postgres-xxx.
Database	Long	The database used by the client to connect to the database instance.
UserName	String	The username used by the client to connect to the database instance.
ErrMsg	String	Original SQL error logs.
ErrTime	String	Error occurrence time.

Parameter	Description
Destination region	Select the region for log shipping, supporting offsite shipping.
Log topic operations	Log topics serve as the fundamental units for collecting, storing, retrieving, and analyzing log data. You can either select an existing log topic or create a new one.
Logset	Logsets serve as a classification mechanism for log topics, enabling efficient management of log topics. You can either select existing log topics or create new ones as needed. Select an existing logset: You can filter existing logsets in the search box to categorize slow log shipping. Create a logset: You can create a new logset to categorize slow log shipping. Only English letters, digits, and underscores are supported, and the length cannot exceed 20.
Log Topic	Select an existing log topic: This option is available only when an existing logset is selected. You can filter log topics under the selected logset in the search box. Create a log topic: Create a new log topic under the selected logset. Only English letters, digits, and underscores are supported, and the length cannot exceed 20. Note: You can manage log topics. For details, see Managing Log Topics.

TencentDB for PostgreSQL

User Guide

Product Documentation

Contents

User Guide

Instance Management

Instance Lifecycle

Setting Instance Maintenance Time

Overview

Directions

Setting maintenance time

Switching now

Modifying Instance Configuration

Overview

Directions

Setting instance availability zone for disaster recovery or region disaster recovery

Setting Cross-AZ Disaster Recovery

Overview

Notes

Fees

Directions

To create an instance, select an AZ on the Purchase page

Modifying an Availability Zone in the Console

Setting Cross-Region Disaster Recovery

Directions

Modifying AZs

Background

Notes

Costs

Directions

Selecting AZs on the instance purchase page

Modifying AZs in the console

Terminating Instances

Overview

Notes

Directions

Restoring Instances

Overview

Directions

Eliminating Instances

Overview

Directions

Restarting Instances

Notes

Directions

Modifying Data Replication Mode

Supported Methods to Replicate Data

Asynchronous Replication

Semi-synchronous Replication

Degradation Description

Fault Degradation

Latency Degradation

Failover Description

Modifying Data Replication Mode

Switch Source-Replica Instance

Reason for Master/Slave Switch

Failover

Manual Switch

Forced Switch

Impact of Master/Slave Switch

Manual Switch of Instances

View Change Record

Master/Slave Latency Monitoring Metrics

Task List

Task Type

Viewing the Task List

Searching Keywords

Downloading Task Data

Viewing Task Details

Upgrading Instance

Instructions for Upgrading Kernel Minor Version

Overview

Extreme Conditions

Impact of Kernel Minor Version Upgrades

Kernel Minor Version Upgrade Principle Explanation

Upgrade Necessity

Upgrade Processing Process

Compatibility Check

Confirm Upgrade Sequence

Upgrading a Read-Only Instance

Operation Type	Backup Type	Operation Details
Data Backup	Data Backup	The system will trigger a full data backup according to your automatic backup setting within the specified time. The backup method is physical backup, which offers fast backup speed and higher recovery efficiency. The generated full automatic backup data is retained based on the data backup retention time you set. The backup data will not be deleted when the instance is terminated. It will be automatically deleted when it expires. This can meet your need to extend the retention of backup data to prevent serious impact due to accidental deletion of instances. Since full backup uses backup storage space, you can delete it promptly if necessary. The automatic backup data within one week cannot be deleted, while data older than one week can be flexibly deleted according to your needs. Please be cautious when deleting backup data as it cannot be recovered after deletion.
		Manual Backup	You can manually initiate a full instance backup based on application needs through the console. After the manual backup task is initiated, the system will perform a full instance backup using the physical backup method within 1 minute. The expiration time of manual backups is one week after they are initiated. Since manual backups occupy backup storage space, you can delete manual backups promptly if necessary.
		Incremental Backup	Incremental backup is WAL log backup, which is automatically enabled by default and cannot be disabled. The incremental backup is stored based on the data backup retention time you set. The system will perform real-time backup based on the WAL log generated by the database. Since incremental backup occupies backup storage space, you can delete it promptly if necessary. Incremental backup data within a week is not allowed to be deleted, while data older than one week can be flexibly deleted according to your needs. After the incremental backup data is deleted, point-in-time recovery cannot be performed, so exercise caution when deleting incremental backup data.
Backup Files Download	Download Full Backup	Supports local browser download and download by address.
Backup Files Download		Download Incremental Backup	Supports local browser download and download by address.
Transfer Historical Backup Through Serverless Cloud Function	Transfer through Serverless Cloud Function	You can transfer historical backup data using the Serverless Cloud Function. For more information, please see Use Serverless Cloud Function to transfer historical PostgreSQL backup.

Parameter	Description
Backup Start Time	Support selecting the default time (to perform backup during idle time of resources throughout the day) or customizing the backup start time. The backup will be initiated within this time range. If the backup fails to be initiated within this time period due to an unexpected reason, this backup will no longer start and will be initiated during the next backup start time period. Default time is the backup initiation time automatically assigned by the system. Support custom selection of backup start time. Set it to the off-peak period. Backup initiation time is merely the time when the backup starts and does not represent the backup end time. For example, if you select 02:00 - 06:00 to enable backup, the system will initiate backup at a certain point within the time range of 02:00 - 06:00, depending on the backend backup policy and backup system status.
Weekly Backup	Select by the scale of one week, and support consecutive or interval selection from Monday to Sunday. Chosen by default for Monday to Sunday, 7 days. Support custom selection of backup time. However, to ensure the security of your data, please set up at least two backups per week.
Weekly backup retention time	Weekly backup files can be retained for 7–1830 days. It defaults to 7 days. The backup set will be auto-deleted upon expiry.
Monthly Backup	Select based on a one-month (31 days) scale. The backup data backed up monthly can be set with a separate retention time. Off by default. After turning on the switch, you can choose any number of days from 1 to 31. Particularly, if the 31st is selected, the backup this time will be skipped directly in months without the 31st. Monthly backup and weekly backup are carried out simultaneously, and all data will be stored.
Monthly backup retention time	Monthly backup files can be retained for 7–1830 days. It defaults to 7 days. The backup set will be auto-deleted upon expiry.
log backup retention time	Log backup data retention time setting: Retainable for 7–1830 days, defaults to 7 days.

Parameter	Description
host	The connection address of the TencentDB for PostgreSQL instance.
port	The port of the TencentDB for PostgreSQL instance.
username	The account name of the TencentDB for PostgreSQL instance.
-Fc	Output format, which is suitable for pg_restore for restoration.
dbname	The name of the database to be exported.
dumpdir	The path and name of the exported backup file.

Type	Source	Retention policy	Space Usage Cost	Recovery Operations	Delete Operation
auto	Automatically generated by the system.	By default, backups are retained for 7 days from the generation time. Users can also customize the setting. For details, please refer to Automatic Backup Settings.	Consistent with the instance running pricing. For details, please refer to Backup Space Billing.	Recover by backup set or time point recovery.	If a backup set contains data within 2 days, it cannot be deleted.
Manual	Users can save by themselves. For details, please refer to Data Backup.	Permanent retention.	Consistent with the instance running pricing. For details, please refer to Backup Space Billing.	Recover by backup set or time point recovery.	Self-service deletion.
Final	The instance is automatically generated by the system when it is put into the recycle bin and completely cleared upon expiration.	Retention period: 8 days from generation time.	No charge.	Recover by backup set or time point recovery.	Non-deletable, can only be automatically cleared by the system upon expiration.

Category	Description
Supported versions	1. Source database Self-built databases PostgreSQL 10-16 Third-party cloud vendors 10-16 Alibaba Cloud RDS PostgreSQL AWS RDS PostgreSQL Huawei Cloud RDS for PostgreSQL TencentDB for PostgreSQL 10-16 (Migration within the same root account/Migration between different root accounts) 2. Target database TencentDB for PostgreSQL 10-16
Impact on the source database	1. During full data migration, Data Transfer Service (DTS) consumes certain source instance resources, which may increase the load and pressure of the source database. If your database configuration is low, we recommend you perform the migration during off-peak hours. 2. During the actual migration process, the rate can be influenced by factors such as the read performance of the source instance, network bandwidth between the source and target instances, and the specifications and performance of the target instance. The migration concurrency is determined by the number of cores of the target instance. For example, if the target instance has 2 cores, the concurrency will be 2.
Migration object	Interrelated data objects need to be migrated together; otherwise, the migration will fail. Common association relationships include: views referencing tables, views referencing views, storage procedures/functions/triggers referencing views/tables, and table association through primary and foreign keys.
Source database requirements	When Full + Incremental Migration is selected as the migration type, the tables in the source database must have primary keys; otherwise, data inconsistency between the source and target databases may occur. For tables without primary keys, it is recommended to select Full Migration.
Target database requirements	If the entire instance is to be migrated, the target database must not contain users and roles with the same names as those in the source database.
Network description	1. When a migration task is configured, the source database address must use the IP address and port that can directly connect to the PostgreSQL instance. Do not use the IP address and port of proxies like pgpool. 2. To ensure migration efficiency, cross-region migration is not supported for self-built instances on Cloud Virtual Machine (CVM). If cross-region migration is needed, choose the public network access method.
Operation limits	1. During the structural migration, full migration, and incremental migration, do not perform DDL operations or Large Object operations; otherwise, data inconsistency will occur. 2. Do not modify or delete user information (including the username, password, and permissions) and port numbers in the source and target databases during migration.

Configuration Item	Description
Source Instance Type	Choose according to your source database type. It cannot be modified after purchase. This example uses "PostgreSQL".
Source Instance Region	Select the region of the source database. If the source database is a self-built one, select a region nearest to it.
Target Instance Type	Choose according to your target database type. It cannot be modified after purchase. This example uses "PostgreSQL".
Target Instance Region	Select the region of the target database.
Specification	Select the specification of a migration link according to your business conditions. For the performance and billing details of different specifications, see Billing Overview.

Setting Type	Configuration Item	Description
Task Configuration	Task Name	Set a business-significant name for easy task identification.
		Running Mode	Immediate execution: Start a task immediately after passing task verification. Scheduled execution: Set a task execution time, and the task will start when the time is reached.
		Tag	Tags are used to manage resources by category from different dimensions. If the existing tags do not meet your requirements, go to the console to manage the tags.
Source Database Settings	Source Database Type	The source database type selected at the time of purchase, which cannot be modified.
		Region	The source database region selected at the time of purchase, which cannot be modified.
		Access Type	Choose according to your scenario. This example uses "Database". For preparation work for different access types, refer to Overview of Preparations Related to Network. To ensure migration efficiency, cross-region migration is not supported for self-built instances on CVM. If cross-region migration is needed, choose the public network access method. Public Network: The source database can be accessed via a public IP address. When migrating via the public network, ensure that the source instance service is accessible under the public network environment and that the public network connection remains stable. Network fluctuations or failures may cause the migration to fail. If the migration fails, a new migration task will need to be initiated. Self-Build on CVM: The source database is deployed on a Tencent CVM. To ensure migration efficiency, cross-region migration is not supported for self-built instances on CVM. If cross-region migration is needed, choose the public network access method. Direct Connect: The source database can be connected to Tencent Virtual Private Cloud via Direct Connect. VPN Access: The source database can be connected to Tencent Virtual Private Cloud via VPN Connections. Database: The source database is a TencentDB instance. CCN: The source database can be connected to Tencent Virtual Private Cloud via Cloud Connect Network.
		Cross-/Intra-Account	Intra-account: The source database instance and the target database instance belong to the same Tencent Cloud root account. Cross-account: The source database instance and the target database instance belong to different Tencent Cloud root accounts. The following is an example of migration within the same account. For cross-account migration guidance, refer to Cross-Account TencentDB Instance Migration.
		Database Instance	Select the instance ID of the source PostgreSQL database.
		Account	The account of the source PostgreSQL database, which must have the required permissions.
		Password	The password of the source PostgreSQL database account.
Target Database Settings	Target Database Type	The target database type selected at the time of purchase, which cannot be modified.
		Region	The target database region selected at the time of purchase, which cannot be modified.
		Access Type	Choose according to your scenario. This example uses "Database" by default.
		Database Instance	Select the instance ID of the target database.
		Account	The account of the target database, which must have the required permissions.
		Password	The password of the target database account.

Configuration Item	Description
Migration Type	Choose according to your scenario. Structural migration: Migrate structured data such as databases and tables. Full migration: Migrate the entire database. The migrated data includes only the existing data of the source database when a task is initiated and does not include the incremental data written to the source database after a task is initiated. Full + Incremental migration: The migrated data includes the existing data of the source database when a task is initiated as well as the incremental data written to the source database after a task is initiated. If data is being written to the source database during migration, and you want to smoothly migrate the data in a non-stop manner, select this option.
Migration Object	Entire instance: Migrate the entire instance, excluding system databases such as system objects in PostgreSQL. However, roles and user metadata definitions will be migrated. Specify object: Migrate specified objects.
Specify object	Select the objects to be migrated in Source Database Object and move them to the Selected Object box.

Item	Details
Overview	Comparison Type: All are currently Independent Check. Comparison Method: The available options are Full comparison, Sampling, and Row count check. Structure Verification: The available options are Enabled and Disabled. Status: The current status of the verification task, which can be Created, Awaiting Execution, Running, or Completed. Compare Conclusion: The result of the current verification task, which can be Inconsistent or Consistent. Thread Count: The number of threads configured for the current task.
Estimated Tables	The system's estimated total number of tables that need verification.
Checked Tables	The number of tables that have currently been successfully checked.
Inconsistent Tables	The number of tables with inconsistencies between the source and target ends among the tables that have already been checked. You can view specific inconsistent tables in Details.
Inconsistent Chunks	The number of chunks with inconsistencies between the source and target ends among the tables that have already been checked. During system verification, chunks are used for verification at both ends, with each chunk containing 10,000 rows of data.

Major Version	Kernel Version
10	v10.17_r1.5
11	v11.12_r1.5
12	v12.7_r1.5
13	v13.3_r1.4
14	v14.2_r1.11
15	v15.1_r1.4
16	v16.0_r1.2