BUG: Aurora PostgreSQL doesn't clean up internal replication slots after Blue/Green deletion

Question

Hi AWS team,

We're encountering what seems to be a **critical issue or bug** in Aurora PostgreSQL's internal slot cleanup behavior.

After removing a Blue/Green deployment from our cluster (`....-prod-aurora`), we noticed that several **internal replication slots** with names like:

rds_us_east_1_...

…were **not removed automatically**, and are now stuck in the system.

These slots:
- Are `active = false`
- Still hold `catalog_xmin`, which is **blocking autovacuum** and `VACUUM FREEZE`
- Have `confirmed_flush_lsn` stuck for hours
- Cannot be dropped using `pg_drop_replication_slot(...)`, even as `rds_superuser` (error: "must be superuser or replication role")

We’ve tested this behavior multiple times in the past, and in all previous cases, the internal replication slots were **automatically removed** after deleting Blue/Green deployments.  
However, in this most recent case, the slots were not cleaned up and remain stuck in an inactive state.

This seems to be an **exception to the expected behavior**, and may indicate a bug or failure in the internal cleanup process.

This is causing OldestReplicationSlotLag to increase, and could eventually lead to transaction ID wraparound, which may seriously impact database stability.

We’re currently on the Basic Support Plan and unable to open a technical support case, so we’re kindly asking if someone from AWS can help investigate or assist with this issue.

### 🙏 We would greatly appreciate any help or advice on:
1. Is this a known bug or limitation?
2. Will Aurora eventually clean up these slots? If so, after how long?
3. Could someone from AWS help clear them for us?
4. Is there anything we can do from our side, without Developer Support?

**Thank you so much in advance.**

re:Post Agent · Answer

This appears to be an issue with inactive replication slots remaining after a Blue/Green deployment deletion in Aurora PostgreSQL.

When you delete a Blue/Green deployment in Aurora PostgreSQL, the behavior of replication slots depends on how the deployment was deleted:

1. If you delete a Blue/Green deployment before switchover:
- If you choose to delete the DB cluster in the green environment, the replication slots should be removed.
- If you retain the green environment, for Aurora PostgreSQL, the green environment is promoted to a standalone environment and replication stops, but inactive slots may remain.

2. If you delete after switchover, the behavior is different, and there's a possibility that inactive replication slots remain in the system.

Inactive replication slots can prevent autovacuum from cleaning up internal catalog tables, leading to catalog bloat and increased risk of transaction ID wraparound, which aligns with the issue you're experiencing.

To address this issue:

1. You can try dropping the inactive replication slot using:
```
SELECT pg_drop_replication_slot('slot_name') WHERE active = 'f'
```
However, as you've noted, this requires superuser privileges which you may not have as rds_superuser.

2. Since you're on the Basic Support Plan, your options are limited. The slots may eventually be cleaned up by Aurora's internal maintenance processes, but there's no documented timeframe for this.

3. Without Developer Support or higher, you cannot open a technical support case to have AWS manually remove these slots.

4. Consider upgrading your support plan temporarily to Developer or higher to get assistance with this issue, as it could potentially lead to more serious problems if left unresolved.

5. As a preventive measure for future Blue/Green deployments, ensure you're following the recommended practices for deletion, which may help avoid this issue.

This does appear to be an exception to the expected behavior, as you mentioned that in previous cases the slots were automatically removed.  
**Sources**  
[Deleting a blue/green deployment in Amazon Aurora - Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-deleting.html)  
[Resolving identifiable vacuum blockers in Aurora PostgreSQL - Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.html)  
[Resolving identifiable vacuum blockers in RDS for PostgreSQL - Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.html)

BUG: Aurora PostgreSQL doesn't clean up internal replication slots after Blue/Green deletion

🙏 We would greatly appreciate any help or advice on:

Add your answer

Relevant content