Date: Thu, 19 Feb 2026 08:01:36 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, Fujii Masao <masao.fujii@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Zsolt Parragi <zsolt.parragi@percona.com>
Subject: Re: Flush some statistics within running transactions
Message-ID: <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
References: <CAA5RZ0tgr5iFuBDofX9n4SNbo-SFjzNFqTGHt7yQFAmfWBf-Rw@mail.gmail.com>
 <CAA5RZ0sqJzpBZnOY3rOy5x7+WL_UDnoMkn2S_ZoXPPOWZkXSbA@mail.gmail.com>
 <aYXL6XmVABORjGF5@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tK=-Dukr4ofmKpPSK4-LwqrGXmzkqGoMuJKPXnGW3=AA@mail.gmail.com>
 <aZLVDJLTiFlxsWZi@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0tPsU_bCATn-Wtf8hMaKmrCwfxtLcY9Pp3NQPpLrH2G_Q@mail.gmail.com>
 <aZQTCJJm61J/X4nC@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vDh+vbE5SY-+azQBxEhXrywaXGrK_Qn8DKEBwNsrDH_Q@mail.gmail.com>
 <aZVQ3nT9B6ti8whJ@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZaKVOrRO_bHsevn@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aZaKVOrRO_bHsevn@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/aZbDYMrOkeCyIubO%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Thu, Feb 19, 2026 at 12:58:12PM +0900, Michael Paquier wrote:
> On Wed, Feb 18, 2026 at 05:40:46AM +0000, Bertrand Drouvot wrote:
> > PFA a mandatory rebase (nothing that needs review) due to a92b809f9da1.
> 
> I don't find the design of this patch appealing, and my mind points
> towards two pieces of it:
> 1) The new requirement related to pgstat_schedule_anytime_update()
> that a stats kind needs to call to enable a timeout.  This partially
> doubles with pgstat_report_fixed.  And I suspect that this extra set
> of requirements, introducing a new level of complexity for in-core
> stats kinds as well as extension developers, would be the source of
> more bugs.

Yeah, maybe we should re-think the way we report that we have something to flush,
but I think that's more a general discussion that should also take care of
pgstat_report_fixed.

> 2) The timeout requirement itself, relying on a timeout threshold
> controlled by a backend-side configuration.

What are you concerns with this? 

> With that in mind, wouldn't it be simpler if we introduced an API that
> could be used from client applications instead, in a model similar
> what we do for procsignal.c/h? 

That's another angle to look at it but I think that giving this responsability to
the clients would not solve the concerns we had in [1] (that led to 039549d70f6
and to this thread). It seems to me that a solution/design that does not allow
us to "revert" 039549d70f6 does not suit our needs. Thoughts?

> Not a fan of the hardcoded sleeps in the tests, either. 

Yeah, after our off-list discussion yesterday, I tried to implement the same
trick that f1e251be80a has done with injection points (nice trick by the way!),
but that led to:

TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "mcxt.c", Line: 1237
postgres: main: walwriter (ExceptionalCondition+0x9e)[0xc4ce4d]
postgres: main: walwriter (MemoryContextAlloc+0x8c)[0xc8f0ec]
postgres: main: walwriter (MemoryContextStrdup+0x37)[0xc8fea1]
postgres: main: walwriter (pstrdup+0x22)[0xc8fee4]
postgres: main: walwriter (substitute_path_macro+0x65)[0xc56068]
postgres: main: walwriter [0xc55e90]
postgres: main: walwriter (load_external_function+0x59)[0xc553db]
postgres: main: walwriter [0xc7b858]
postgres: main: walwriter [0xc7c125]
postgres: main: walwriter (IsInjectionPointAttached+0x18)[0xc7c20c]
postgres: main: walwriter (pgstat_count_backend_io_op+0x12f)[0xa9a116]
postgres: main: walwriter (pgstat_count_io_op+0x169)[0xa9cb57]
postgres: main: walwriter (pgstat_count_io_op_time+0x1cc)[0xa9cda7]

So, I did not spend that much time on it. I could if we strongly think that those
sleeps have to be discarded though.

[1]: https://postgr.es/m/erpzwxoptqhuptdrtehqydzjapvroumkhh7lc6poclbhe7jk7l%40l3yfsq5q4pw7

Regards,

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