Re: Improve pg_stat_statements scalability

Hello,

At Thu, 2 Jul 2026 12:57:38 -0500, Sami Imseih <samimseih(at)gmail(dot)com> 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