Re: pgstat: Flush some statistics within running transactions, take 2

Hi,

On Sun, Aug 30, 2026 at 09:48:38PM -0500, Sami Imseih wrote:
> Hi,
>
>
> > === 1
> >
> > Thanks! Looking closer, I think there is still another window though:
> >
> > pgstat_unlock_entry() calls LWLockRelease(), which can process a pending
> > interrupt. At that point, the shared relation stats have been updated,
> > while the
> > database pending stats and flushed baseline have not. A later retry could
> > then
> > apply the same delta again.
> >
> > That is also already possible in HEAD and should be very rare in practice.
> > That
> > said, I think it is worth mentioning and deciding whether we want to
> > handle this
> > case too.
> >
>
> I looked at this a bit more. We could close the window you mention
> either by moving pgstat_unlock_entry() until after the pending
> database stats are updated, or by holding interrupts across both the
> shared relation/index update and the pending database update.
>
> But there are still other windows where the relation/index stats and
> database stats can diverge, including a possible double count in the
> database entry, in particular between finishing the relation/index
> flush callbacks and later flushing the database stats.
>
> So I would rather not do anything here for now, including v8-0001,
> and instead take it up in a separate thread. WDYT?

Yeah, given that those windows already exist in HEAD I think it makes sense
to open a dedicated thread.

> > Should we clear this flag between passes, or at least check
> > pgStatFlushInProgress
> > here?
>
>
> Yeah right. I will fix this and send out a new rev.

Thanks!

Regards,

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