Procedure calls are not tracked in pg_stat_user_functions / track_functions
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t39450psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 07:57 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t39450_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t39450_3 && git checkout t39450_3Patchset v3 (message #3) is on t39450_3
Hi all,
It seems that currently procedures do not get tracked when track_functions
is enabled, which means one needs to resort to other workarounds in order
to monitor procedure calls/runtime.
To illustrate:
=# SHOW track_functions;
┌─────────────────┐
│ track_functions │
├─────────────────┤
│ all │
└─────────────────┘
(1 row)
=# CALL abc();
CALL
=# SELECT def();
┌─────┐
│ def │
├─────┤
│ │
└─────┘
(1 row)
=# SELECT * FROM pg_stat_user_functions;
┌─[ RECORD 1 ]────────────────────┐
│ funcid │ 75223 │
│ schemaname │ public │
│ funcname │ def │
│ calls │ 1 │
│ total_time │ 3.222 │
│ self_time │ 3.222 │
└────────────┴────────────────────┘
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.
Thanks,
Lukas
--
Lukas Fittl
Hi,
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Hi all,
It seems that currently procedures do not get tracked when track_functions
is enabled, which means one needs to resort to other workarounds in order
to monitor procedure calls/runtime.To illustrate:
=# SHOW track_functions;
┌─────────────────┐
│ track_functions │
├─────────────────┤
│ all │
└─────────────────┘
(1 row)=# CALL abc();
CALL=# SELECT def();
┌─────┐
│ def │
├─────┤
│ │
└─────┘
(1 row)=# SELECT * FROM pg_stat_user_functions;
┌─[ RECORD 1 ]────────────────────┐
│ funcid │ 75223 │
│ schemaname │ public │
│ funcname │ def │
│ calls │ 1 │
│ total_time │ 3.222 │
│ self_time │ 3.222 │
└────────────┴────────────────────┘Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.
Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.
- Andres
On 04/10/2018 22:07, Andres Freund wrote:
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.
Here is a patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 05/10/2018 14:15, Peter Eisentraut wrote:
On 04/10/2018 22:07, Andres Freund wrote:
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
Was this intentional, or an oversight?
If welcome, I would be happy to work on a patch. Whilst slightly confusing
in terms of naming, we could just track this together with functions, since
one can always join with pg_proc to determine whether something is a
function or a procedure.Yea, that sounds wrong / not ideal to me. I think we should just fix
this, should be easy enough.Here is a patch.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services