On Tue, Nov 18, 2025 at 4:05 PM Ashutosh Bapat <[email protected]> wrote: > > On Tue, Nov 18, 2025 at 3:24 PM Amit Kapila <[email protected]> wrote: > > > > On Tue, Nov 4, 2025 at 4:29 PM Ashutosh Bapat > > <[email protected]> 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.
