Horton

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

Álvaro Herrera <alvherre@kurilemu.de>

View thread View on postgr.es
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Michael Paquier <michael@paquier.xyz>
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-20T11:09:59Z
Lists: pgsql-bugs 
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/

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