Re: Report bytes and transactions actually sent downtream

Hi Michael,

On Wed, Mar 25, 2026 at 12:25 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Mar 18, 2026 at 09:58:58AM +0530, Ashutosh Sharma wrote:
> > So the right boundary for sent_bytes is according to me would be:
> >
> > a) include logical decoding payload sent downstream (or via SQL
> > decoding path), whether it came from transactional changes or
> > non-transactional logical messages
> > b) exclude auxiliary replication protocol traffic such as keepalives
> >
> > If this makes sense then the revised documentation shared by Ashutosh
> > Bapat in his last email looks good to me, which is:
> >
> > Amount of transaction changes and non-transactional messages sent
> > downstream in the output plugin
> > format for this slot. The output plugin may filter the changes it
> > receives. Hence the amount of data that it converts to the output
> > plugin format is less than the <structfield>total_bytes</structfield>.
> > But the format of data before and after the conversion is different.
> > Hence the value of <structfield>sent_bytes</structfield> is not
> > directly related to the value of
> > <structfield>total_bytes</structfield>.
> >
> > If you all agree with this, I will first prepare a patch to fix the
> > missing part in #2 which is about reporting stats for
> > non-transactional messages that goes via logical decoding process and
> > then on top of that share the ongoing 0001 patch with above doc
> > change.
>
> Amit Kapila and I have both mentioned that the definition you are
> putting behind the sent_bytes field, as in "not accounting for the
> protocol messages required in the publisher-subscriber exchange"
> mentioned in b), feels strange, because these messages are sent over
> the wire and part of the exchanges, like the decoded data.

If we start including protocol messages such as keepalives in
sent_bytes, we may end up in situations where sent_bytes exceeds
total_bytes. All byte-related columns in the pg_stat_replication_slots
catalog currently refer specifically to decoded transactional data -
none of them account for non-transactional data or data that didn't go
through logical decoding. Including keepalive data in sent_bytes could
therefore cause it to exceed total_bytes, which would likely add
confusion and make the data harder for users to interpret.

--
With Regards,
Ashutosh Sharma.