# Investigating WAL Growth from an Inactive Postgres Replication Slot on Amazon RDS

DevFeed: [Investigating WAL Growth from an Inactive Postgres Replication Slot on Amazon RDS](<https://devfeed.tech/articles/the-insatiable-postgres-replication-slot-18834.md>)

Original publisher: [Read original article](<https://www.morling.dev/blog/insatiable-postgres-replication-slot/>)

Published: 2022-11-30T13:00:00Z

Content type: article

Language: en

Sources: [Gunnar Morling](<https://devfeed.tech/sources/gunnar-morling.md>)

Topics: [Replication](<https://devfeed.tech/topics/replication.md>), [Amazon RDS](<https://devfeed.tech/topics/amazon-rds.md>), [apache-flink](<https://devfeed.tech/topics/apache-flink.md>), [Database](<https://devfeed.tech/topics/database.md>)

Tags: [amazon](<https://devfeed.tech/tags/amazon.md>), [amazon-rds](<https://devfeed.tech/tags/amazon-rds.md>), [apache-flink](<https://devfeed.tech/tags/apache-flink.md>), [database](<https://devfeed.tech/tags/database.md>), [debezium](<https://devfeed.tech/tags/debezium.md>), [disk-space](<https://devfeed.tech/tags/disk-space.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [replication](<https://devfeed.tech/tags/replication.md>), [storage](<https://devfeed.tech/tags/storage.md>)

## AI overview

This article investigates how an inactive Postgres replication slot on Amazon RDS can retain WAL segments and consume disk space even when the database appears idle. It reproduces the behavior and compares replication-slot LSN differences with RDS storage and transaction-log metrics.

## Source excerpt

Table of Contents The Observation The Solution Take Away While working on a demo for processing change events from Postgres with Apache Flink, I noticed an interesting phenomenon: A Postgres database which I had set up for that demo on Amazon RDS, ran out of disk space. The machine had a disk size of 200 GiB which was fully used up in the course of less than two weeks. Now a common cause for this kind of issue are replication slots which are not advanced: in that case, Postgres will hold on to all WAL segments after the latest log sequence number (LSN) which was confirmed for that slot. Indeed I had set up a replication slot (via the Decodable CDC source connector for Postgres, which is based on Debezium). I then had stopped that connector, causing the slot to become inactive. The problem was though that I was really sure that there was no traffic in that database whatsoever! What could cause a WAL growth of ~18 GB/day then?