Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ltTqD-0000uD-HM
	for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jun 2021 11:36:17 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ltTqB-0003Oj-Ea
	for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Jun 2021 11:36:15 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <torikoshia@oss.nttdata.com>)
	id 1ltTqB-0003Ob-6n
	for pgsql-hackers@lists.postgresql.org; Wed, 16 Jun 2021 11:36:15 +0000
Received: from oss.nttdata.com ([49.212.34.109])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <torikoshia@oss.nttdata.com>)
	id 1ltTq8-00067R-GF
	for pgsql-hackers@postgresql.org; Wed, 16 Jun 2021 11:36:14 +0000
Received: from oss.nttdata.com (localhost [127.0.0.1])
	by oss.nttdata.com (Postfix) with ESMTPA id C8F5560A15;
	Wed, 16 Jun 2021 20:36:08 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.2 at oss.nttdata.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Jun 2021 20:36:08 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Pgsql Hackers
 <pgsql-hackers@postgresql.org>
Subject: Re: RFC: Logging plan of the running query
In-Reply-To: 
 <CALj2ACVeOvBcN2-MZh-P3FKxsxOv-DD=fUgAMQEY8vPEhoJUQw@mail.gmail.com>
References: <cf8501bcd95ba4d727cbba886ba9eea8@oss.nttdata.com>
 <CAFiTN-vE4Q6=bJ-n9hNz8qwkaw2NK1scNC5LrSFkREex+XymLg@mail.gmail.com>
 <CALj2ACXDiOhAdXks_w2b5NGg=7_K27Lx1Gau_iQnxGBCNkSMnQ@mail.gmail.com>
 <CALj2ACXpvVeLstnNG1Oris0VpxbSdLNdh_r-v6YxTEY5vcDHAA@mail.gmail.com>
 <CAFiTN-tbi83fB0j0S7-kj9TraUkim03M3S+oXdYe6sMZ7nxVYA@mail.gmail.com>
 <CALj2ACVH-fhO5htnM2UbV7mvP3+0+zYHBamCTC8KWTtSb5+8=g@mail.gmail.com>
 <CAFiTN-vQcDtyc5aRF1RNo-VgRzMcZ4E1qKTybvHpzUV1FEjqBA@mail.gmail.com>
 <CALj2ACWiVHpOqEztxHRtUR1oiDzPGUnguqv2EfEmQSv7jH93aw@mail.gmail.com>
 <CAFiTN-vOTFRK1xoAWRAGJ+54mSpDxmenAFexbySRhgy7hNH5Fg@mail.gmail.com>
 <CAFiTN-u6yqaxQyfX0jUMqDZ22fePfuQuQmzuozTxC34ca+ZByg@mail.gmail.com>
 <c6682a25f3f0e9bd520707342219eac5@oss.nttdata.com>
 <0842b5da697a03869fb50be93817e4e1@oss.nttdata.com>
 <CALj2ACUpznbsLbOg9mauSQZfU2eDxnNLYXcBHaAp1yWxMKLK9g@mail.gmail.com>
 <1c1590d3962cea6e06621da76677b5f3@oss.nttdata.com>
 <CALj2ACVeOvBcN2-MZh-P3FKxsxOv-DD=fUgAMQEY8vPEhoJUQw@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <dfc25182d91ed9491f77c0c8ca5b71fd@oss.nttdata.com>
X-Sender: torikoshia@oss.nttdata.com
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/dfc25182d91ed9491f77c0c8ca5b71fd%40oss.nttdata.com>
Precedence: bulk

On 2021-06-15 13:27, Bharath Rupireddy wrote:
> On Mon, Jun 14, 2021 at 5:48 PM torikoshia <torikoshia@oss.nttdata.com> 
> wrote:
>> > 1) We could just say "Requests to log query plan of the presently
>> > running query of a given backend along with an untruncated query
>> > string in the server logs."
>> > Instead of
>> > +        They will be logged at <literal>LOG</literal> message level
>> > and
>> > +        will appear in the server log based on the log
>> > +        configuration set (See <xref
>> > linkend="runtime-config-logging"/>
>> 
>> Actually this explanation is almost the same as that of
>> pg_log_backend_memory_contexts().
>> Do you think we should change both of them?
>> I think it may be too detailed but accurate.
> 
> I withdraw my comment. We can keep the explanation similar to
> pg_log_backend_memory_contexts as it was agreed upon and committed
> text. If the wordings are similar, then it will be easier for users to
> understand the documentation.
> 
>> > 5) Instead of just showing the true return value of the function
>> > pg_log_current_plan in the sql test, which just shows that the signal
>> > is sent, but it doesn't mean that the backend has processed that
>> > signal and logged the plan. I think we can add the test using TAP
>> > framework, one
>> 
>> I once made a tap test for pg_log_backend_memory_contexts(), but it
>> seemed an overkill and we agreed that it was appropriate just ensuring
>> the function working as below discussion.
>> 
>> https://www.postgresql.org/message-id/bbecd722d4f8e261b350186ac4bf68a7%40oss.nttdata.com
> 
> Okay. I withdraw my comment.
> 
>> > 6) Do we unnecessarily need to signal the processes such as autovacuum
>> > launcher/workers, logical replication launcher/workers, wal senders,
>> > wal receivers and so on. only to emit a "PID %d is not executing
>> > queries now" message? Moreover, those processes will be waiting in
>> > loops for timeouts to occur, then as soon as they wake up do they need
>> > to process this extra uninformative signal?
>> > We could choose to not signal those processes at all which might or
>> > might not be possible.
>> > Otherwise, we could just emit messages like "XXXX process cannot run a
>> > query" in ProcessInterrupts.
>> 
>> Agreed.
>> 
>> However it needs to distinguish backends which can execute queries and
>> other processes such as autovacuum launcher, I don't come up with
>> easy ways to do so.
>> I'm going to think about it.
> 
> I'm not sure if there is any information in the shared memory
> accessible to all the backends/sessions that can say a PID is
> autovacuum launcher/worker, logical replication launcher/worker or any
> other background or parallel worker.

As far as I looked around, there seems no easy ways to do so.

> If we were to invent a new
> mechanism just for addressing the above comment, I would rather choose
> to not do that as it seems like an overkill. We can leave it up to the
> user whether or not to unnecessarily signal those processes which are
> bound to print "PID XXX is not executing queries now" message.

+1. I'm going to proceed in this direction.

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION