Re: Report bytes and transactions actually sent downtream

On Tue, Nov 18, 2025 at 4:05 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Tue, Nov 18, 2025 at 3:24 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Tue, Nov 4, 2025 at 4:29 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > a. sentTxns and filteredBytes need to be modified in the output plugin
> > > code. The behaviour there is inherently output plugin specific, and
> > > requires output plugin specific implementation.
> > >
> >
> > Is it possible that we allow change callback (LogicalDecodeChangeCB)
> > to return a boolean such that if the change is decoded and sent, it
> > returns true, otherwise, false? If so, the caller could deduce from it
> > the filtered bytes, and if none of the change calls returns true, this
> > means the entire transaction is not sent.
> >
> > I think this should address Andres's concern of explicitly tracking
> > these stats in plugins, what do you think?
> >
>
> I was thinking about a similar thing. But I am skeptical since the
> calling logic is not straight forward - there's an indirection in
> between. Second, it means that all the plugins have to adapt to the
> new callback definition. It is optional in my current approach. Since
> both of us have thought of this approach, I think it's worth a try.
>
> "if none of the change calls returns true, this means the entire
> transaction is not sent" isn't true. A plugin may still send an empty
> transaction. I was thinking of making commit/abort/prepare callbacks
> to return true/false to indicate whether a transaction was sent or not
> and increment the counter accordingly. The plugin has to take care of
> not returning true for both prepare and commit or prepare and abort.
> So may be just commit and abort should be made to return true or
> false. What do you think?
>

Sounds reasonable to me.

--
With Regards,
Amit Kapila.