Re: Flush some statistics within running transactions

Hi,

On Sun, Feb 22, 2026 at 08:12:06PM -0600, Sami Imseih wrote:
> > > I took a look at this today out of interest,
> >
> > Thanks!
> >
> > > so, instead of calling IS_INJECTION_POINT_ATTACHED macro which is
> >
> > I think that not calling IS_INJECTION_POINT_ATTACHED() but only relying on
> > "ifdef USE_INJECTION_POINTS" would set the tiny timeout value to the entire test
> > suit.
> 
> Yes, you are right about that.

And even if we are able to set a tiny timeout to say N in the test, the test
would still need a pg_sleep(N+). So I wonder if the best way is not to 
re-introduce pg_stat_force_anytime_flush() that was in v6?

> To Michael's earlier comments:
> 
> For variable-length statistics, perhaps we can do things a bit
> differently than what is currently proposed. 0005 requires
> a relation anytime stat update to call
> pgstat_schedule_anytime_update(). This is done this way because
> it allows long-running queries to update their stats every
> stats_flush_interval using a timeout.
> 
> But maybe what we should be doing for variable-numbered stats is
> to schedule an anytime update whenever a "transaction goes idle".

I think the logic for fixed stats and variable stats should be the same. If
not we could observe discrepancies: for example a long running select could
genereate reads/hits IO visible in pg_stat_io but tuples_returned, tuples_fetched,
blocks_fetched or blocks_hit would not be updated until the session goes idle.

> I find it odd to ask applications/clients to trigger a flush. I am not saying
> that we should not offer such an API, especially if someone want to flush
> stats more frequently than stats_flush_interval,

Yeah, and that could help with the tests to avoid the sleep.

> but there should be
> the ability for core to handle this automatically outside of the transaction
> boundaries.

Agreed. I think that public facing API could be an addition, not a replacement.

> One comment about the current test. I think there is a bug that was
> missed in the earlier review. For the var_anytime_update, we need to
> have an escape before the pipe.
> 
> -like($result, qr/^entry2|2|/m,
> +like($result, qr/^entry2\|2\|/m,

Oh right, thanks! The attach rewrites it like the fixed test instead.

Also the attached introduces a mandatory rebase due to 308622edf17.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com