Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wZwqa-001QPI-16 for pgsql-bugs@arkaria.postgresql.org; Wed, 17 Jun 2026 20:26:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZwqX-007XO0-01 for pgsql-bugs@arkaria.postgresql.org; Wed, 17 Jun 2026 20:26:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wZwqW-007XNs-2R for pgsql-bugs@lists.postgresql.org; Wed, 17 Jun 2026 20:26:48 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZwqU-00000000yNB-1wLI for pgsql-bugs@lists.postgresql.org; Wed, 17 Jun 2026 20:26:48 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-beb1bee8c16so23711966b.0 for ; Wed, 17 Jun 2026 13:26:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781728005; cv=none; d=google.com; s=arc-20240605; b=FX5RlD+T7qqm2Lmfoa4zhakWe9Zi7PoDRvm4jsju6r4vJR4sNVAie6AhUyWpG1uk7c EDf0A+O12ARmOfUl6DR2G/KrwFvZssUGNI9ENA82fYSytcMKIP/235P1Cdsd67BTSEmx x/agN0q1JoVFQH6JW8npWSvIqFIqEK8vbkOgSvJLhJPykLEZVegOO6fvAxQEJMThRD26 ofUXRpOuDoZEuLLslwXj8Bbm83kh25XRrYSPCJ8iJuK2r/SzbphWxpu1r+78aEv1s0rN Ndvgv8K+x4m5ABl45JRf12OTyOokUck+nc8LW9/YvdMTzszvjUasn5khRX+1MPSBQspi BOBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=6o7SFHmuUO9zUpMdU8tiXQ3kzKIsNKpZiErp1mdNtKM=; fh=MadL5ZgVz2Z+XwzkwilPFmFbrvilfiSeqZQ1tKS255Q=; b=IKOFtXd1BZVLhAoFDt8mdJgZBipr49eL+zWSbDpP8ucdFVz/0mo4eFtrbBfYaLLOgF GangJtasWF/WslcJH1UjbYAtRE98aromWg4ZvyDqa+fwAjhRT8YmnMRyHPWuwQEp2Lx5 vF3om/a6gatz/E+GR4a+Aug2iUQtmrRvnacHz9QtU3fsTJJ5h83VwXNb2by8x1zhpz+I QmffUGXAMuLKc20W9dQjbQ2lWSw1PtXadB+9QPZVBo+rq6+quxtdoxKTjkVNzIjtWbSI oEWXshQqrVahMAOewlKOfzr6DSAOKqHKq5XrmKFTo5NFaMTmkA/dK4QFjh1H/9VkMnJu 4vjg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781728005; x=1782332805; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6o7SFHmuUO9zUpMdU8tiXQ3kzKIsNKpZiErp1mdNtKM=; b=am0rvA50vR7DSbWgeF3W9j87t9/VDxhAEcnQsbXf4Fg/bennXOT/QvVY7OmPp59FfS lF3dSkOiCHX4KHtaFiuOfzNJBISTB3ww/Shsjc4fNzmrFpBnffwAhxARj+Uy/nK4FiOz e6ATacxRKWI+GXEaxDLDBMMeCea+2+tBK3huUGmEu+T6Ymp0ZSFd7Zb/PX4iJqcmP4/J uYQoBBze6V8fPQX1Pk3P14F57Ocw2ZXXi41rftOfELpONmUKIJ9m1nwSerjxCWvqWcPa zc6kS7HjWvpbcitmyB50dwGSvtMATXtLL8UQQEgMsXimNkVclQQ7OLuvngWWk30bb/mq Sf2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781728005; x=1782332805; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6o7SFHmuUO9zUpMdU8tiXQ3kzKIsNKpZiErp1mdNtKM=; b=icyzbp7zYwxcaZpbI/UMTAKUazDDjvbLFsphetGFSmvBmqONyzoD35n3YWSrN56Gv8 cUnFJ/r62ikk65AJQMiRmuTsXRHFs+zKGit7/3QwyaljDl+hvsKFQf+pfPrkBxSAuvbl x7GUlKOQbHUEaxZPknLej8+LCHiX5nBjIsfKcvgE72kN/1gzFcC1DPWTEevnogSxX27d yJVM4FE1ffEayuoliYuLh5M7A3yHDy7BeDmkcdjNYr19Q4AaZWshQAiJ1OgXQGEmL1+c xQROtoTijPMKCzlDYNK/f1ZCkRyXF6gq/TbXLGz+du1GbgeoNRoE+jYwTtsTynszsDZI rMfQ== X-Forwarded-Encrypted: i=1; AFNElJ/KW9zDVa1Q4r4RT9Rm08HJ09pUSo0E7fJjcSgC/sLkD+v9sDKISuH0DQqReyDTG9Mu3k8q0DeLS9TC@lists.postgresql.org X-Gm-Message-State: AOJu0Yxans2y6VSwlHEqnjFsbfVQF8FB9RFxnh9LQUULtj1NKRY0KPUS qoZfkPjPpFuZXhoAfoPZSW2KB1j+IYCvouHIs1dpSwDK5FEoVe/uWdMmuceLy3X5RVdSIo8uuBi NguNUhchLzn9l2tMxYzdyIur9K2GL0PA= X-Gm-Gg: Acq92OHj78HPLrZgItRef4sy1FQsn874MQuLXTozrOYlHIJ4ayfm3GAguracecsGHJd ky08tym5VckKdHCiwuI5AlSULKvmtn+7I2vAL/b6KfPDiCShTtoz/LucWX85f/L7AsEHpvgu64r mC149hDWpice66o8oVYG2N/RWec18ZxkUdXvNYBOpHZDNfAV+Lgg8rKpuTJFTptumDWAHUjh+is U5HuZHwnInUpWOan3UbjhqPbuVdThLP7HTSH0r+xR4j1a0G1uv5l/+m7ulq6HrUrIpP8laCdaqg pHcrYm6+FZ2LC5vgMogxzRxZURWydVp5D5MpIg== X-Received: by 2002:a17:907:d508:b0:c07:6a7e:3a40 with SMTP id a640c23a62f3a-c076a7e404dmr15563566b.10.1781728004557; Wed, 17 Jun 2026 13:26:44 -0700 (PDT) MIME-Version: 1.0 References: <19520-73873648d44793cf@postgresql.org> In-Reply-To: From: Sami Imseih Date: Wed, 17 Jun 2026 15:26:33 -0500 X-Gm-Features: AVVi8Cdd2NGJljElfnTS0PX8VgrY_umO5Alg9h-LU8I3glgvKbc95bVIYD4eNLU Message-ID: Subject: Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions = To: Ayush Tiwari Cc: Michael Paquier , zlh21343@163.com, pgsql-bugs@lists.postgresql.org, Andres Freund , Kyotaro Horiguchi Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > This patch is very close to what Sami has posted on his PGSS thread, > v3-0002, using a missing_ok instead of a skip_dropped: > https://www.postgresql.org/message-id/CAA5RZ0uoxiQ2_=xHGRnyc4WdM9aR0fzdMhBubnw97po==--yGQ@mail.gmail.com > I didn't suspect that we would need something like that for a > backpatch, but well. Right, my intention was just adding infrastructure to make tolerating a dropped entry possible and to be used by an extension in the future. But, this bug report is timely and now it looks like we need this for race conditions that are possible in core. > A couple of things which I'm not clear about (these are not blockers > just questions for my understanding): > > - With the check moved into the wrapper, pgstat_drop_entry_internal() > still keeps its own "already dropped" elog(). Every path into > _internal now seems to guarantee the entry isn't dropped, so > _internal's copy looks unreachable after the patch > ,and it's the one with the richer refcount/generation detail. Right. Michael's approach of moving the ERROR into the wrapper is better than keeping it in _internal. Since after the patch no caller enters pgstat_drop_entry_internal() with a dropped entry (pgstat_drop_database_and_contents() and pgstat_drop_matching_entries() already filtered them out, and now the wrapper does too) > 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 > - 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. -- Sami Imseih Amazon Web Services (AWS)