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 1vLZ6S-003WEo-0U for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Nov 2025 03:43:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vLZ6Q-00APii-2S for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Nov 2025 03:43:31 +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.96) (envelope-from ) id 1vLZ6Q-00APiO-1V for pgsql-hackers@lists.postgresql.org; Wed, 19 Nov 2025 03:43:30 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vLZ6N-000Gyd-0S for pgsql-hackers@lists.postgresql.org; Wed, 19 Nov 2025 03:43:29 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTPA id 5E970612E7; Wed, 19 Nov 2025 12:43:23 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 19 Nov 2025 12:43:22 +0900 From: torikoshia To: Akshat Jaimini Cc: pgsql-hackers@lists.postgresql.org Subject: Re: RFC: Logging plan of the running query In-Reply-To: <176349718657.1015.12677520994128141938.pgcf@coridan.postgresql.org> References: <5fbde7ee5e41cc2ad6012bf273a9539d@oss.nttdata.com> <176349718657.1015.12677520994128141938.pgcf@coridan.postgresql.org> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <4d067d7934fd94f696e72feedc5fc1f9@oss.nttdata.com> X-Sender: torikoshia@oss.nttdata.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025-11-19 05:19, Akshat Jaimini wrote: Thanks for your review! > Hi, > I have a question: > > In src/backend/executor/execMain.c: > > ``` > + SetCurrentQueryDesc(oldQueryDesc); > + > + /* > + * Ensure LogQueryPlanPending is initialized in case there was no > time for > + * logging the plan. Othewise plan will be logged at the next query > + * execution on the same session. > + */ > + LogQueryPlanPending = false; > ``` > > It would be really helpful if you could elaborate on any cases where > this specific situation might arise i.e. where 'there was no time for > logging the plan'. Are we referencing to something like a sudden > shutdown of the postmaster process or is this referring to something > else entirely? What I have in mind are cases where a query finishes before LogQueryPlan() is ever invoked. Since LogQueryPlan() is called from ExecProcNodeFirst(), this generally means pg_log_query_plan() was called at the moment just before query execution completes. Also, very short queries fall into this category: =# select pg_log_query_plan(pg_backend_pid()); pg_log_query_plan ------------------- t (1 row) =# select 1; With the current patch, nothing is logged here. But if I comment out the "LogQueryPlanPending = false" line, the plan for "SELECT 1" ends up being logged: LOG: 00000: query and its plan running on backend with PID 33040 are: Query Text: select 1; Result (cost=0.00..0.01 rows=1 width=4) Output: 1 Settings: jit = 'off' -- Regards, -- Atsushi Torikoshi Seconded from NTT DATA Japan Corporation to SRA OSS K.K.