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
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? |