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

On 2026-Jun-18, Michael Paquier wrote:

> And I did see one spot here, where there is a
> pgstat_custom_drop_entry() that maps to a definition of
> pgstat_drop_entry():
> https://github.com/pganalyze/pg_stat_plans
>
> I'll go file a ticket.

Is this really the right reaction? As you know, for the extension
developers it is much more difficult to handle the ABI change on their
side, because they need to force all their users to update the extension
prior to updating Postgres. This is pretty difficult to do normally and
can lead to crashes on production. As extension developer you can try
to communicate this, but for end users it is quite easy to miss it.

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.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/