> You're looking for Standby Status Update
Awesome! I completely missed that.
> Transactions are always presented to the output plugin in commit order
Ok great. I think that is what I needed to know.
Just to confirm, it sounds like the order messages are sent from the output plugin is what matters here. When you update confirmed_flush_lsn to LSN "A", any messages that were sent by the output plugin after the message with LSN "A" will be replayable. Any messages sent by the output plugin before the message with LSN "A" will most likely not be replayed, since their data is freed for deletion. Is that correct?
On Tue, Mar 25, 2025 at 11:32 PM Christophe Pettus <xof@xxxxxxxxxxxx> wrote:
> On Mar 25, 2025, at 20:56, Phillip Diffley <phillip6402@xxxxxxxxx> wrote:
>
> Is there a message type that is used to confirm what logs have been successfully consumed?
You're looking for Standby Status Update:
https://www.postgresql.org/docs/current/protocol-replication.html#PROTOCOL-REPLICATION-STANDBY-STATUS-UPDATE
The logical replication protocol is a superset of the binary replication protocol, so many of the same messages are used.
> The part I am uncertain about is what "after" means here, since LSNs are not presented in order, and the order of data streamed over the replication slot does not match the order of the data in the WAL.
I think there's a misunderstanding here (possibly my fault). Transactions are always presented to the output plugin in commit order, and LSNs can be reliably used to determine the time ordering of commits. LSNs are exactly what is used to determine how far into the WAL the replication slot has gotten.
