This topic describes the use cases, background, technical solution, procedure, and FAQ for the global consistency feature.
Overview
PolarDB for PostgreSQL provides a global consistency feature at the database kernel level. This feature ensures that read requests sent to any node in a cluster return strongly consistent results.
Applicability
This feature is supported on the following versions of PolarDB for PostgreSQL:
PostgreSQL 16 (minor engine version 2.0.16.9.9.0 or later).
PostgreSQL 14 (minor engine version 2.0.14.11.22.0 or later).
You can view the minor engine version in the console or by running the SHOW polardb_version; statement. If the minor engine version of your cluster does not meet the requirements, you can upgrade the minor engine version.
Background information
In the original one-writer, multi-reader architecture of PolarDB, read-only nodes provide session consistency by default. Although physical replication and shared storage technologies effectively reduce the replication delay of read-only nodes, they cannot ensure that requests sent to read-only nodes always read the most recent data written to the RW node. This delay can cause business logic inconsistencies in latency-sensitive industries such as finance and gaming.
As shown in the preceding figure, business applications are often decoupled using a microservice framework. After Service A writes data, it generates a write success message and notifies Service B through a message queue component. In a session consistency scenario, after Service A updates the value of the col column to 20, it can immediately read the updated value of 20 within the same session, even if the request is routed to a read-only node. However, after Service A notifies Service B of the data update, if Service B reads directly from a read-only node, it may not retrieve the latest result and may still read 10. This can cause data consistency issues for the application. In this scenario, the application can only forward read requests to the RW node to ensure read-after-write data consistency. This leaves the resources of read-only nodes idle.
Technical solution
PolarDB for PostgreSQL provides a strong consistency read capability for read-only nodes at the database kernel level. This ensures that read-only nodes can always read the latest data written to the RW node, which provides cluster-wide strong consistency for read operations. After you enable the global consistency feature, each read-write transaction committed on the RW node is assigned a Commit Sequence Number (CSN). The CSN indicates the transaction commit order and is used to build a more efficient transaction snapshot that replaces the active transaction list of native PostgreSQL. The RW node also records the CSN in the Write-Ahead Log (WAL). Read-only nodes then replay the WAL to construct a complete transaction state.
The SQL execution process for strong consistency reads on a read-only node is as follows:
A client sends a query request to a read-only node.
The read-only node obtains the latest CSN from the RW node over the network.
The read-only node uses the latest CSN from the RW node to build a strong consistency read view and waits for the transaction state of the read-only node to be replayed to the corresponding offset.
The read-only node determines data visibility based on the strong consistency read view and returns the result to the client.
Procedure
Log on to the PolarDB console.
In the navigation pane on the left, click Clusters.
In the upper-left corner, select the region where the cluster is deployed.
Find the target cluster and click its ID.
In the navigation pane on the left, choose . Set the
polar_csn_enableandpolar_global_csn_enableparameters toonto enable the CSN feature for transactions.NoteYou must restart the cluster for the parameter modifications to take effect. Plan this operation in advance and proceed with caution. For more information about how to set cluster parameters in the console, see Set cluster parameters.
On the Basic Information page of the target cluster, in the Database Connections section, click Configure next to Cluster Endpoint or click Settings in the dialog box that appears.

On the endpoint configuration page, set Consistency Level to Global Consistency (Strong) and configure the two related parameters:
Parameter
Description
Global Consistency Timeout
The timeout period for a read-only node to wait for data synchronization from the primary node to ensure consistency. Valid values: 1 to 1,000,000. Unit: ms. Default value: 100.
Global Consistency Timeout Policy
The policy to apply when a read-only node times out. Valid values:
0, Send Requests to Primary Node (Default).
1, Return Error Messages Due to Timeout.
2, Automatic Downgrade to Inconsistent Read Due to Timeout