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 ajND7FDG6MfiJfux@paquier.xyz
Whole thread
In response to Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =  (Sami Imseih <samimseih@gmail.com>)
Responses Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =
List pgsql-bugs
On Wed, Jun 17, 2026 at 03:26:33PM -0500, Sami Imseih wrote:
>> Was the idea to leave it as a backstop, or would folding the handling into
>> one place (or making _internal's an Assert) be cleaner?
>
> The check in _internal should be converted to an Assert. This documents
> that callers  must only pass "live" entries, which will be the case
> for all callers after
> the patch

Yeah, I was hesitating to do so, but perhaps you are right that there
is little meaning in keeping this extra elog() anymore in the internal
routine: all its callers discard entries marked as dropped.  And we do
so while holding an exclusive lock.

>> - In the missing_ok path the wrapper returns true, so the post-commit
>>   caller skips the not_freed_count++/GC request that a "real" not-freed
>>   drop would do.  That seems harmless since the entry self-heals
>>   but was returning true there a deliberate choice over mirroring
>>   the not-freed/false path? I need to take a look again at this, maybe
>>   I missed something.
>
> Finding an already dropped entry tells me that the first caller to drop the
> entry also triggered a gc request, so we should not request it again.

Nope, we should not trigger multiple requests.

Attaching an updated patch for now.  I am still testing it locally
across all the branches to make sure that the issue is gone (that
takes quite a bit of time).  I'll probably apply it in a few hours
down to v15 if nothing pops up.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #19521: After a minor PostgreSQL update from 14.22 to 14.23, the database goes into an infinite loop.
Next
From: Ayush Tiwari
Date:
Subject: Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =