Hello, At Thu, 2 Jul 2026 12:57:38 -0500, Sami Imseih <[email protected]> wrote in > The callback is ultimately responsible for knowing what to flush depending > on the state ( in transaction --or-- end of transaction )
I agree with that part. The callback certainly needs to know what can be flushed in the current context. What I was trying to separate is the callback's flush logic from the meaning of its return value. Previously, the callback's return value indicated whether the requested flush completed, for example, whether it failed to acquire a lock. With this change, the same value would also indicate that some state was intentionally excluded from an in-transaction flush. Although both cases leave the entry pending for a later flush, they represent different outcomes. The callback still needs to determine what can be flushed and whether anything remains. My point is only that intentionally retaining transactional state due to the flush context should not be represented as a failure of the callback's own work. I think it would be cleaner for the caller to combine the callback's result with the flush context when deciding whether to remove the entry from the pending list. Similarly, the context flag is not intended to prevent every developer mistake. Rather, it makes the changed callback contract explicit, so extensions implementing custom stats kinds are forced to revisit their callbacks instead of silently assuming the previous semantics. Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
