On Tue, Mar 17, 2026 at 10:55:51AM +0530, Ashutosh Bapat wrote:
> On Tue, Mar 17, 2026 at 10:32 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Yesterday, I raised a point related to this which is whether we want
>> to count messages like keep_alive, copy_done, or
>> PqReplMsg_PrimaryStatusUpdate? These don't contain the user decoded
>> data from WAL but some additional information between
>> publisher-subscriber required to ensure data is being applied.
>
> I think sent_bytes should count the logically decoded data - the data
> that the output plugin produces in logical form. This is the amount of
> data that the downstream has to process for data replication. So, the
> protocol related data shouldn't be counted here, IMO. Compare this
> with the total_bytes which does not account for the memory used by the
> reorder buffer metadata itself - it just accounts for the size of the
> changes. If we describe the sent_bytes as below, we are explicitly
> mentioning what sent_bytes is. So anything which is not data in the
> output format is excluded including the protocol data. If you think we
> need to clarify that we are excluding protocol data, we can add a
> line. But that may confuse readers who are unaware of the protocol
> data.
As we aim to count how many bytes are sent over the wire, including
the amount of bytes related to the messages sent as part of the
protocol exchanged, sounds like an important property that we should
have in the implementation because these bytes are required for the
exchanges to work. If an output plugin decodes few changes and has a
lot of messages (unlikely in most cases, still imagine it's the case),
sent_bytes could be misleading if we only include the transactional
changes, couldn't it?
--
Michael
