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. This could
be relevant if the exchanges consist of short decoded data and mostly
of protocol data. Of course you are free to send an updated patch
based on the definition you see fit. Whether one agrees or not with
the definition implemented in the patch is a different matter.
Anybody is also free to disagree or overwrite our opinions on the
matter, of course, that's how consensus is driven.
--
Michael
