Horton

Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =

Álvaro Herrera <alvherre@kurilemu.de>

View thread View on postgr.es
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Sami Imseih <samimseih@gmail.com>, zlh21343@163.com, pgsql-bugs@lists.postgresql.org, Andres Freund <andres@anarazel.de>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2026-06-20T16:58:27Z
Lists: pgsql-bugs 
On 2026-Jun-20, Michael Paquier wrote:

> If you feel strongly about it, we could just do something like the
> attached in the v15-v18 range.  This introduces a new routine called
> pgstat_drop_entry_ext() that gains the new argument "missing_ok", and
> pgstat_drop_entry() would be an ABI-compatible wrapper calling it.
> 
> What do you think?

Yeah, this sounds more or less reasonable.  The callers that pass
missing_ok=false could still use the original function name though, no?

(Personally I would do for an ABI compatibility in back branches with
this new function, and an API breakage in master by simply adding the
new argument everywhere, but keeping the old function name.  This way we
don't preserve unnecessary API ugliness forever.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"¿Qué importan los años?  Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo"  (Mafalda)

Commits

  1. Re-introduce pgstat_drop_entry(), keeping ABI compatibility

  2. Update .abi-compliance-history for pgstat_drop_entry()

  3. Fix PANIC with track_functions due to concurrent drop of pgstats entries