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 1lHkLY-0000Yo-Bq
	for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Mar 2021 09:32:40 +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 1lHkLX-0004Fa-6N
	for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Mar 2021 09:32:39 +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 1lHkLW-0004FT-NQ
	for pgsql-hackers@lists.postgresql.org; Thu, 04 Mar 2021 09:32:38 +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 1lHkLU-0002Ei-7k
	for pgsql-hackers@postgresql.org; Thu, 04 Mar 2021 09:32:37 +0000
Received: from oss.nttdata.com (localhost [127.0.0.1])
	by oss.nttdata.com (Postfix) with ESMTP id 40D63602FD;
	Thu,  4 Mar 2021 18:32:33 +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: Thu, 04 Mar 2021 18:32:33 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@oss.nttdata.com>,
 Georgios Kokolatos <gkokolatos@protonmail.com>, Kasahara Tatsuhito
 <kasahara.tatsuhito@gmail.com>, craig@2ndquadrant.com
Subject: Re: Get memory contexts of an arbitrary backend process
In-Reply-To: <40c1a4b19ad03beacee2642a3cd61c14@oss.nttdata.com>
References: <0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com>
 <270ec80dbbebfb5c6f2b9fdd7a7858b5@oss.nttdata.com>
 <160502083340.7362.4386116585349115146.pgcf@coridan.postgresql.org>
 <064d510f2d33edc37dfd6b8f3b6bd30e@oss.nttdata.com>
 <d42d3186-d647-9af4-7c1c-d6ffca8bff40@oss.nttdata.com>
 <1685539.1606959410@sss.pgh.pa.us>
 <83ff0aff04fffc95cbd1fc1637a0fccc@oss.nttdata.com>
 <28e1feb71b94ac9918830bc4a0c1844f@oss.nttdata.com>
 <CAP0=ZV+XcPnX+m9ROG07hs=DqwQCOLAojgvYCRogw=bFAv1+Eg@mail.gmail.com>
 <9a59401241e9269254e70c8e0ef1cc7a@oss.nttdata.com>
 <4ae7b086a5b49fdfec7c1154d6fc7a40@oss.nttdata.com>
 <40c1a4b19ad03beacee2642a3cd61c14@oss.nttdata.com>
Message-ID: <9a50371e15e741e295accabc72a41df1@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>
Archived-At: 
 <https://www.postgresql.org/message-id/9a50371e15e741e295accabc72a41df1%40oss.nttdata.com>
Precedence: bulk

On 2021-01-14 19:11, torikoshia wrote:
> Since pg_get_target_backend_memory_contexts() waits to dump memory and
> it could lead dead lock as below.
> 
>   - session1
>   BEGIN; TRUNCATE t;
> 
>   - session2
>   BEGIN; TRUNCATE t; -- wait
> 
>   - session1
>   SELECT * FROM pg_get_target_backend_memory_contexts(<pid of session
> 2>); --wait
> 
> 
> Thanks for notifying me, Fujii-san.
> 
> 
> Attached v8 patch that prohibited calling the function inside 
> transactions.

Regrettably, this modification could not cope with the advisory lock and
I haven't come up with a good way to deal with it.

It seems to me that the architecture of the requestor waiting for the
dumper leads to this problem and complicates things.


Considering the discussion printing backtrace discussion[1], it seems
reasonable that the requestor just sends a signal and dumper dumps to
the log file.

Since I found a past discussion that was doing exactly what I thought
reasonable[2], I'm going to continue that discussion if there are no
objections.


Any thought?


[1] 
https://www.postgresql.org/message-id/flat/CALDaNm3ZzmFS-=r7oDUzj7y7BgQv+N06Kqyft6C3xZDoKnk_6w@mail.gmail.com
[2] 
https://www.postgresql.org/message-id/flat/20171212044330.3nclev2sfrab36tf%40alap3.anarazel.de#6f28be9839c74779ed6aaa75616124f5


Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION