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-22T08:28:58Z
Lists: pgsql-bugs 
On Sun, Jun 21, 2026 at 07:51:25AM +0900, Michael Paquier wrote:
> Using the old function name in the back-branches where missing_ok is
> false would also work, of course.  My suggestion just makes one less
> call showing up on the stack.  The previous patch posted is not for
> HEAD, only for v15~v18.

By the way, regarding .abi-compliance-history, I am planning to remove
the latest entry after reading how ABICompCheck.pm works in the
buildfarm code.  It uses the latest commit as a base point of
comparison, and compares it with the latest commit specified in the 
ABI file.

Removing the entry in the same commit that adjusts the pgstats routine
to be ABI-compatible should work, and there is no point in adding an
extra entry to re-document the opposite ABI change.  Any comments
perhaps?
--
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