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 1qwGvX-00AlDV-Ja for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 07:06:39 +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 1qwGvW-00COma-9d for pgsql-hackers@arkaria.postgresql.org; Fri, 27 Oct 2023 07:06:38 +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 1qwGvV-00COmS-Uy for pgsql-hackers@lists.postgresql.org; Fri, 27 Oct 2023 07:06:38 +0000 Received: from mail1.dalibo.net ([51.159.93.128] helo=mail.dalibo.com) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qwGvT-002X23-C9 for pgsql-hackers@lists.postgresql.org; Fri, 27 Oct 2023 07:06:36 +0000 Received: from [192.168.1.87] (59.70.69.37.rev.sfr.net [37.69.70.59]) by mail.dalibo.com (Postfix) with ESMTPSA id 809851F897; Fri, 27 Oct 2023 09:06:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dalibo.com; s=a; t=1698390392; bh=yaqNRfePxtrMjaRM3qIyDhThPPWtfkXjhzDp6FVYM+U=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Bwf5Qlq6HBVoN1sayqECjjnWNS4jPW8BJMx4rIfQaCKO8ubkxlRx3CAiR/6mhD00H TQdP69II8THmrl+8rnEoKr6McTlukz7JnVzCgKxnxY5D2mpTOlIrs4iQ653PQUwpNw 1AavlfiYPTgk1wecZy5qSCsfKTvzmg4+0MObbzV0= Message-ID: <7bc1cc1bcc3289e9354ebb00ac1c8440c01b736c.camel@dalibo.com> Subject: Re: RFC: Logging plan of the running query From: =?ISO-8859-1?Q?=C9tienne?= BERSAC To: torikoshia Cc: Ashutosh Bapat , Andres Freund , jtc331@gmail.com, pgsql-hackers@lists.postgresql.org Date: Fri, 27 Oct 2023 09:06:31 +0200 In-Reply-To: <66d29d2c10ca9181c7e183eeeb4525f8@oss.nttdata.com> References: <4e1e4e5d022964953e84468fe4e511b0@oss.nttdata.com> <4af7712833d4ce989cf5e658106e42da@oss.nttdata.com> <7ab57ab0ba3416e2dbf54927752bc310@oss.nttdata.com> <20231006155850.kjjb2vwbkawj7moq@alap3.anarazel.de> <0e0e7ca08dff077a625c27a5e0c2ef0a@oss.nttdata.com> <2d6d7846b6b794c0e727c431852a113c@oss.nttdata.com> <0eb66e8c72f23695957466db5c76c69c@oss.nttdata.com> <9c36599db62ef7466a297843fe812fc60e827cd2.camel@dalibo.com> <66d29d2c10ca9181c7e183eeeb4525f8@oss.nttdata.com> Organization: DALIBO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Torikoshia, > If so, we once tried to implement such function for getting memory=20 > contexts. > However, this attempt didn't succeed because it could lead dead lock=20 > situation[1]. Thanks for the pointer. Why not use client log message to allow client to get plan without locking backend memory context and without access to server log ? I missed the rationnal for not sending the plan to client. Regards, =C3=89tienne