public inbox for [email protected]  

help / color / mirror / Atom feed

From: Rajendra Kumar Dangwal <[email protected]>
To: [email protected]
Subject: Clarification on restart_lsn behavior in logical decoding
Date: Thu, 9 Oct 2025 12:36:27 +0530
Message-ID: <CA+qyiM=5dqKp2qyjoWVQpM1tpDcD7rQxZcgh7gQe73EfLuaUcA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<pyh2kcisxwrhzz255gaiaawo5yubirdifzsfvz3okqcjeaaqqr@6lq5n6idswg7>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi PG users.

We are using PostgreSQL’s logical decoding feature with Debezium to capture
CDC events and stream them to Kafka. To verify whether the required
position to resume from after a connector restart is still available on the
server, we compare the processed LSNs with the restart_lsn of the
replication slot.

From the documentation, our understanding is that restart_lsn represents
the oldest WAL position still required by the logical decoding consumer:

> restart_lsn pg_lsn
> The address (LSN) of oldest WAL which still might be required by the
> consumer of this slot and thus won't be automatically removed during
> checkpoints unless this LSN gets behind more than max_slot_wal_keep_size
> <https://postgrespro.com/docs/postgresql/14/runtime-config-replication#GUC-MAX-SLOT-WAL-KEEP-SIZE; from
> the current LSN. NULL if the LSN of this slot has never been reserved.


However, there is some confusion around the possible value of restart_lsn.
My current understanding is that the restart_lsn cannot be greater than the
start LSN of the oldest open (non-consumed) transaction.
One of my teammates, however, suggested that there might be cases where the
restart_lsn could advance beyond the start LSN of an unconsumed
transaction, as illustrated below:

               LSN
T1 BEGIN
T1 CHANGE 1    20
T1 CHANGE 2    21  <--- Restart LSN
T1 CHANGE 3    22
T1 COMMIT      30  <--- Confirmed flush LSN
T2 BEGIN
T2 CHANGE 1    10  <--- Start LSN of unconsumed transaction
T2 CHANGE 2    11  <--- Last processed LSN
T2 CHANGE 3    12
T2 COMMIT      40

Could someone please clarify whether the restart_lsn can indeed have
value greater than the start LSN of an unconsumed transaction, or if
it is always expected to be less than or equal to it?


Thanks,

Rajendra.

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Clarification on restart_lsn behavior in logical decoding
  In-Reply-To: <CA+qyiM=5dqKp2qyjoWVQpM1tpDcD7rQxZcgh7gQe73EfLuaUcA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox