Inactive replication slots cause write-ahead logging (WAL) logs to accumulate continuously. Left unaddressed, accumulated WAL logs exhaust disk space, lock the instance, and block all write requests. Use the WAL log management feature to identify and delete inactive replication slots before they affect your workload.
Delete inactive replication slots promptly. Accumulating WAL logs can cause the following critical failure:
Instance lock: When disk space is exhausted, the instance switches to read-only mode and rejects all write requests.
Deleted replication slots cannot be reused.
Background
A replication slot tracks replication progress and ensures WAL logs are retained until all subscribers have consumed them. This prevents data loss in streaming replication.
A slot becomes inactive when its subscriber disconnects, is misconfigured, or has a long replication delay. While inactive, the slot holds WAL logs indefinitely — the checkpointer cannot delete them until the slot is removed or reactivated.
Prerequisites
Before you begin, make sure you have:
An ApsaraDB RDS for PostgreSQL instance
Access to the ApsaraDB RDS console
Manage replication slots
View replication slots
In the console:
Go to the Instances page. In the top navigation bar, select the region where your instance resides. Click the instance ID.
In the left-side navigation pane, choose Logs > WAL Logs.
On the WAL File Management tab, review the list of replication slots.
The Whether Active column (mapped to the active field) shows the status of each slot. Slots with INACTIVE status are accumulating WAL logs.
The following table describes all fields on the WAL File Management tab.
| Column | Field in pg_replication_slots | Description |
|---|---|---|
| Slot name | slot_name | The name of the replication slot. |
| Slot type | slot_type | The replication slot type: physical or logical. |
| Plugin | plugin | The output plugin used by the slot. ApsaraDB RDS for PostgreSQL supports test_decoding, pgoutput, and wal2json by default. |
| Temporary slot | temporary | Whether the slot is temporary. A temporary slot exists only for the current session and is deleted automatically when the session ends. Values: true (temporary), false (permanent). |
| Database name | database | The database where the replication slot resides. |
| Accumulated WAL files | Calculated by AliPG | The volume of WAL logs accumulated for the slot, in MB. Calculated using pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn). |
| Logical subscription latency | Calculated by AliPG | The replication lag on the subscriber node corresponding to this slot, in seconds. Calculated from pg_stat_replication. |
| Whether active | active | Whether the slot is in use. Values: ACTIVE, INACTIVE. |
Delete an inactive replication slot
In the console:
On the WAL File Management tab, locate a slot with
INACTIVEin the Whether Active column.If the replication slot is still in use, change the state to ACTIVE.
If the slot is no longer needed, click Delete in the Actions column.
Active replication slots cannot be deleted.
After deletion, WAL logs that were held by the slot are automatically released and cleaned up by the checkpointer.
Usage notes
Active replication slots cannot be deleted.
A deleted replication slot cannot be reused. If replication is still needed, create a new slot.
Related parameters
The following PostgreSQL parameters control WAL log retention and checkpoint behavior. Configure them in instance parameters.
| Parameter | Description |
|---|---|
max_wal_size | The WAL log size that triggers a checkpoint. |
min_wal_size | The minimum WAL log size retained on disk for reuse at a future checkpoint. WAL logs below this threshold are recycled rather than deleted. |
wal_buffers | The amount of shared memory used for WAL data not yet written to disk. |
What's next
API reference
DescribeSlots: Query all replication slots for an instance.
DeleteSlot: Delete a replication slot from an instance.