Re: Get memory contexts of an arbitrary backend process

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Georgios Kokolatos <gkokolatos(at)protonmail(dot)com>, Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>, craig(at)2ndquadrant(dot)com
Subject: Re: Get memory contexts of an arbitrary backend process
Date: 2021-03-05 05:22:56
Message-ID: bea016ad-d1a7-f01d-a7e8-01106a1de77f@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/03/04 18:32, torikoshia wrote:
> 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.

+1

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2021-03-05 05:24:34 RE: libpq debug log
Previous Message Thomas Munro 2021-03-05 05:22:12 Re: pgbench: option delaying queries till connections establishment?