Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Álvaro Herrera <alvherre@kurilemu.de>
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-20T22:51:25Z
Lists: pgsql-bugs 
On Sat, Jun 20, 2026 at 06:58:27PM +0200, Alvaro Herrera wrote:
> 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.)

Yes, that would be the idea:
- On HEAD, keep the old function name, add the parameter.
- On the back-branches, use the new function name with the new
parameter.  And contrary to you limit the use of the old function
name.

Using the old function name in the back-branches where missing_ok is
false would also work, of course.  My suggestion just makes one less
call showing up on the stack.  The previous patch posted is not for
HEAD, only for v15~v18.
--
Michael

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