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-20T12:15:50Z
Lists: pgsql-bugs

Attachments

On Sat, Jun 20, 2026 at 01:09:59PM +0200, Alvaro Herrera wrote:
> I think a better answer is to just not introduce the ABI change in
> stable branches.  That is, I think we should add a shim function so that
> the third-party extensions can continue to use the original ABI; and
> only in master you clean that up with a different API, whereby the
> extension will be forced to have an #ifdef block for the 19 version or
> the older versions, but that's fine because the extension has to be
> recompiled for the new major version anyway so the end-user won't be
> affected on a minor upgrade.

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