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 1lGas1-0002ld-2H
	for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Mar 2021 05:13:25 +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 1lGarz-0008U1-VL
	for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Mar 2021 05:13:23 +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 1lGarz-0008Tu-OG
	for pgsql-hackers@lists.postgresql.org; Mon, 01 Mar 2021 05:13:23 +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 1lGarw-0007Vw-9N
	for pgsql-hackers@lists.postgresql.org; Mon, 01 Mar 2021 05:13:22 +0000
Received: from oss.nttdata.com (localhost [127.0.0.1])
	by oss.nttdata.com (Postfix) with ESMTP id 3366D62728;
	Mon,  1 Mar 2021 14:13:16 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 01 Mar 2021 14:13:16 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Andres
 Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Craig Ringer
 <craig.ringer@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Peter
 Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
In-Reply-To: 
 <CALDaNm3aBt1hw+Q=achUxfQgyu3b6DmdxewvMVx5DEikNayAFA@mail.gmail.com>
References: <20210115201011.noomcygirzge43ir@alap3.anarazel.de>
 <CALDaNm2wjFrizmy+yvNbedYKxorZBcGYXNMaoPC6zwSaLsmwLg@mail.gmail.com>
 <3537.1610828491@sss.pgh.pa.us>
 <CA+TgmobpOhhm0poFsShjoM=sOxkbzc78f2TdNyZpGz4GSJHh6g@mail.gmail.com>
 <492025.1611078655@sss.pgh.pa.us>
 <CA+TgmoZ8XeQVCCqfq826kAr804a1ZnYy46FnQB9r2n_iOofh8Q@mail.gmail.com>
 <523589.1611091371@sss.pgh.pa.us>
 <CAGRY4nxmyaGs4-o4JSMwsUmqe++y-9zPEmJTeRn5ZOOdNzxi5w@mail.gmail.com>
 <799340.1611194209@sss.pgh.pa.us>
 <CALDaNm1ig4dKFW1658YBH9338Oysc-MT6-YzeKU-ojv87MhhMQ@mail.gmail.com>
 <20210127170958.vzo33jzmqwhmn7z6@alap3.anarazel.de>
 <CALDaNm1uWKn8KGD0q8HqCPhxSUDKWCEW55aidOiJwd+vfaB+gg@mail.gmail.com>
 <CALj2ACXfXefmdUWiF0twoYEfgJ6Xk4saXctoYyzXtzkjizCdBw@mail.gmail.com>
 <CALDaNm0aEUNLZeiDAXvPsgm4nFUjUhtfeztGofmVJU--irSD8Q@mail.gmail.com>
 <CALj2ACXybys_tzWeatb9htVTuxKp29VErc6iJQYJBbdBZXv2fg@mail.gmail.com>
 <CALDaNm3aBt1hw+Q=achUxfQgyu3b6DmdxewvMVx5DEikNayAFA@mail.gmail.com>
Message-ID: <979ee93ab2e5d7d51836ced0c38b445c@oss.nttdata.com>
X-Sender: torikoshia@oss.nttdata.com
User-Agent: Roundcube Webmail/1.1.9
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>
Precedence: bulk

Hi,

I also think this feature would be useful when supporting
environments that lack debugger or debug symbols.
I think such environments are not rare.


+        <xref linkend="runtime-config-logging"/> for more information. 
This
+        will help in identifying where exactly the backend process is 
currently
+        executing.

When I read this, I expected a backtrace would be generated at
the moment when it receives the signal, but actually it just
sets a flag that causes the next CHECK_FOR_INTERRUPTS to print
a backtrace.

How about explaining the timing of the backtrace generation?


+        print backtrace of superuser backends. This feature is not 
supported
+        for postmaster, logging and statistics process.

Since the current patch use BackendPidGetProc(), it does not
support this feature not only postmaster, logging, and
statistics but also checkpointer, background writer, and
walwriter.

And when I specify pid of these PostgreSQL processes, it
says "PID xxxx is not a PostgreSQL server process".

I think it may confuse users, so it might be worth
changing messages for those PostgreSQL processes.
AuxiliaryPidGetProc() may help to do it.


diff --git a/src/backend/postmaster/checkpointer.c 
b/src/backend/postmaster/checkpointer.c
index 54a818b..5fae328 100644
--- a/src/backend/postmaster/checkpointer.c
+++ b/src/backend/postmaster/checkpointer.c
@@ -57,6 +57,7 @@
  #include "storage/shmem.h"
  #include "storage/smgr.h"
  #include "storage/spin.h"
+#include "tcop/tcopprot.h"
  #include "utils/guc.h"
  #include "utils/memutils.h"
  #include "utils/resowner.h"
@@ -547,6 +548,13 @@ HandleCheckpointerInterrupts(void)
         if (ProcSignalBarrierPending)
                 ProcessProcSignalBarrier();

+       /* Process printing backtrace */
+       if (PrintBacktracePending)
+       {
+               PrintBacktracePending = false;
+               set_backtrace(NULL, 0);
+       }
+

Although it implements backtrace for checkpointer, when
I specified pid of checkpointer it was refused from
BackendPidGetProc().


Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION