Clarification on restart_lsn behavior in logical decoding

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.