MIME-Version: 1.0
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> <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
In-Reply-To: <aZbDYMrOkeCyIubO@ip-10-97-1-34.eu-west-3.compute.internal>
From: Sami Imseih <samimseih@gmail.com>
Date: Thu, 19 Feb 2026 16:08:59 -0600
Message-ID: <CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q@mail.gmail.com>
Subject: Re: Flush some statistics within running transactions
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Fujii Masao <masao.fujii@gmail.com>, 
	pgsql-hackers@lists.postgresql.org, Zsolt Parragi <zsolt.parragi@percona.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAA5RZ0u2Vi4-PvHsFBS6aHpoi-uNQjDaLxnAwXxRuUf6ZDMs3Q%40mail.gmail.com>
Precedence: bulk

> > 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.

I took a look at this today out of interest, based on what you mentioned to me
offline.

There is this in injection_points.c

```
/*
* Load an injection point into the local cache.
*
* This is useful to be able to load an injection point before running it,
* especially if the injection point is called in a code path where memory
* allocations cannot happen, like critical sections.
*/
void
InjectionPointLoad(const char *name)
{
#ifdef USE_INJECTION_POINTS
InjectionPointCacheRefresh(name);
#else
elog(ERROR, "Injection points are not supported by this build");
#endif
}
```

so, instead of calling IS_INJECTION_POINT_ATTACHED macro which is
called on-demand and in the case of I/O stats, during the critical section,
you can just call INJECTION_POINT_LOAD during pgstat_initialize(),
like this:

```
INJECTION_POINT_LOAD("anytime-update-reduce-timeout");
```

Sami Imseih
Amazon Web Services (AWS)