Clarification on restart_lsn behavior in logical decoding - Mailing list pgsql-general

From Rajendra Kumar Dangwal
Subject Clarification on restart_lsn behavior in logical decoding
Date
Msg-id CA+qyiM=5dqKp2qyjoWVQpM1tpDcD7rQxZcgh7gQe73EfLuaUcA@mail.gmail.com
Whole thread Raw
List pgsql-general
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 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.

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Alerting on memory use and instance crash
Next
From: KK CHN
Date:
Subject: Pgbackrest changing RepoServer to new one