Re: Report bytes and transactions actually sent downtream

On Tue, Mar 17, 2026 at 10:15 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > Observation: I do not see UpdateDecodingStats() being triggered for
> > this non-transactional message.
> >
>
> I think that is probably a bug. I see that ReorderBufferQueueMessage()
> queues messages for transactional messages and which would then
> probably be sent later along with commit, so its data will be counted
> by UpdateDecodingStats. But the question is shouldn't we consider the
> data for non-transactional messages as well?
>

I am also replying to your earlier comment

> BTW, this also contains changes from pgoutput_message() which could be
> non-transactional. So, saying transaction changes may not be
> appropriate.
>

We should consider the non-transactional messages as well in
sent_bytes, since that amount of data is sent. Whether we can use the
term "transaction changes" in the description of sent_bytes if we
include non-transactional messages is questionable. I used
"transactional changes" in the description of "sent_bytes" to be
consistent with the description of total_bytes. Looks like you are
suggesting that not accounting for non-transaction messages in
total_bytes is a bug, if we fix that, are we going to fix the
description of "total_bytes"? If yes, it makes sense to mention
non-transactional messages separately in sent_bytes description. We
can modify my previous suggestion as

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>.

--
Best Wishes,
Ashutosh Bapat