Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions = - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =
Date
Msg-id ajaEdjQ8A7o-UqMU@paquier.xyz
Whole thread
List pgsql-bugs
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

Attachment

pgsql-bugs by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: BUG #19484: Segmentation fault triggered by FDW
Next
From: Fujii Masao
Date:
Subject: Re: BUG #19528: Assert failure in generate_normalized_query() via Squashed Array Literals