# Postgres Replication Slots: Confirmed Flush LSN vs. Restart LSN

DevFeed: [Postgres Replication Slots: Confirmed Flush LSN vs. Restart LSN](<https://devfeed.tech/articles/postgres-replication-slots-confirmed-flush-lsn-vs-restart-lsn-18859.md>)

Original publisher: [Read original article](<https://www.morling.dev/blog/postgres-replication-slots-confirmed-flush-lsn-vs-restart-lsn/>)

Published: 2025-08-05T11:55:00Z

Content type: tutorial

Language: en

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

Topics: [Replication](<https://devfeed.tech/topics/replication.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>)

Tags: [capture](<https://devfeed.tech/tags/capture.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [database](<https://devfeed.tech/tags/database.md>), [debezium](<https://devfeed.tech/tags/debezium.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [replication](<https://devfeed.tech/tags/replication.md>), [retention](<https://devfeed.tech/tags/retention.md>), [stream](<https://devfeed.tech/tags/stream.md>), [streaming](<https://devfeed.tech/tags/streaming.md>), [transactions](<https://devfeed.tech/tags/transactions.md>), [troubleshooting](<https://devfeed.tech/tags/troubleshooting.md>)

## AI overview

This tutorial explains the difference between PostgreSQL replication slots' confirmed_flush_lsn and restart_lsn attributes. It describes how consumers resume from replication slots, how concurrent transactions affect the oldest WAL that may still be required, and why understanding both LSNs helps with troubleshooting and WAL retention.

## Source excerpt

Table of Contents confirmed_flush_sn: Tracking Consumer Progress restart_lsn: Handling Concurrent Transactions Mid-Transaction Recovery Looking Forward: Streaming In-Progress Transactions Replication slots in Postgres keep track of how far consumers have read a replication stream. After a restart, consumers--either Postgres read replicas or external tools for change data capture (CDC), like Debezium--resume reading from the last confirmed log sequence number (LSN) of their replication slot. The slot prevents the database from disposing of required log segments, allowing safe resumption after downtime. In this post, we are going to take a look at why Postgres replication slots don't have one but two LSN-related attributes: restart_lsn and confirmed_flush_lsn. Understanding the difference between the two is crucial for troubleshooting replication issues, optimizing WAL retention, and avoiding common pitfalls in production environments.