On Tue, Mar 17, 2026 at 10:15 AM Amit Kapila <[email protected]> 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
