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

On Sat, Jun 20, 2026 at 5:16 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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?

As the developer of the extension in the picture, I was actually
surprised to see the commit making an ABI *and* API breaking change
(and I think with cumulative stats being pluggable in 18, we can
expect people to use public stats functions like pgstat_drop_entry in
extensions), precisely because of the issues Alvaro mentioned.

I think doing it with a new routine is what I would have expected to
happen to preserve API and ABI compatibility, and your follow-up patch
looks good to me.

Thanks,
Lukas

--
Lukas Fittl