On Tue, Jun 04, 2024 at 02:25:23PM +0900, Michael Paquier wrote:
>> This does mean it's unfortunately unrelated to the issue I reported
>> here
>>
https://www.postgresql.org/message-id/flat/20240505223546.6yvjzgqifuoiii3e%40awork3.anarazel.de#1dfe3ecf6a75ace833444bdc0d268f4a
>> , because the issue in the current thread is fixed by changing a
>> replication-slot call (which is not used in the database for which I
>> reported it).
>
> Yeah, It's clear that we don't have enough information to proceed
> here. It seems to me that there is a good argument for addressing
> this one first, separately of the other one.
I have been playing with this patch and scenarios of replslot
create/drop similar to what's been sent at the top of this thread, and
the solution proposed is proving to be stable enough to not see a
problem in the pgstats machinery after letting the test run 30 minutes
or so (switched sleep intervals for one).
Attached is an updated patch with refined comments at the top of
pgstat_drop_entry(), to be applied to 15~.
I'm kind of feeling that this is not the end of it, even if the use of
the drop routine is inconsistent in this code path. Perhaps that's
just my spidey sense being incorrect here..
--
Michael