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.94.2) (envelope-from ) id 1u2cYd-003MPc-JP for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Apr 2025 21:02:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u2cYc-007JEK-0t for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Apr 2025 21:02:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u2cYb-007JBw-M3 for pgsql-hackers@lists.postgresql.org; Wed, 09 Apr 2025 21:02:01 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u2cYa-003wOo-0Q for pgsql-hackers@lists.postgresql.org; Wed, 09 Apr 2025 21:02:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 539L1u0W327808; Wed, 9 Apr 2025 17:01:56 -0400 From: Tom Lane To: Alexander Lakhin cc: Alexander Pyhalov , Pavel Stehule , Alexander Korotkov , pgsql-hackers@lists.postgresql.org, Ronan Dunklau Subject: Re: SQLFunctionCache and generic plans In-reply-to: <136163.1744179562@sss.pgh.pa.us> References: <8216639.NyiUUSuA9g@aivenlaptop> <445556.1738612687@sss.pgh.pa.us> <464677.1738620525@sss.pgh.pa.us> <1fc18af56d5fb27bf3e153ffaa2ed70d@postgrespro.ru> <2615770.1740688857@sss.pgh.pa.us> <448c63cf9b4f917c01802309b9c29eb9@postgrespro.ru> <2827970.1741890560@sss.pgh.pa.us> <337e011069b6831e063bfa346f49bb46@postgrespro.ru> <3344719.1741985546@sss.pgh.pa.us> <2691107.1743257329@sss.pgh.pa.us> <3605427.1743351017@sss.pgh.pa.us> <248291.1743463745@sss.pgh.pa.us> <1101294.1743617356@sss.pgh.! pa.us> <0fde377a-3870-4d18-946a-ce008ee5bb88@gmail.com> <1454289.1743707630@sss.pgh.pa.us> <6d442183-! 102c-498a-81d1-eeeb086cdc5a@gmail.com> <2048515.1743803254@sss.pgh.! pa.us> <94b13098-8c2c-4b1a-87e3-579e27d17509@gmail.com> <136163.1744179562@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 09 Apr 2025 02:19:22 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <327806.1744232516.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 09 Apr 2025 17:01:56 -0400 Message-ID: <327807.1744232516@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > I noticed that avocet and trilobite (two of our CLOBBER_CACHE_ALWAYS > animals) have started to fail on the deadlock-parallel isolation > test, with symptoms that look like they're timing out. > ... > The simplest fix is to force that test to use debug_discard_caches=3D0, > but I don't love that answer. Anybody have a better idea? I thought of a better way: we can bypass the need to use a non-inlined SQL function by declaring internal-language aliases for the auxiliary-lock functions that are falsely marked parallel-safe. It's a little bit ugly (see [1]) but I think it beats not running this test under debug_discard_caches at all. regards, tom lane [1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h= =3D837cc73af29cd9c63515a6f2a36f54dd703a3a3f