Re: Get memory contexts of an arbitrary backend process - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Get memory contexts of an arbitrary backend process
Date
Msg-id CALNJ-vQ=x-9AgsVA5fQH_LZQABr+G3ATCPoWE-WFmwjd9Lhp3w@mail.gmail.com
Whole thread Raw
In response to Re: Get memory contexts of an arbitrary backend process  (torikoshia <torikoshia@oss.nttdata.com>)
Responses Re: Get memory contexts of an arbitrary backend process  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers


On Sun, Apr 4, 2021 at 7:56 PM torikoshia <torikoshia@oss.nttdata.com> wrote:
On 2021-04-01 19:13, Fujii Masao wrote:
> On 2021/03/31 15:16, Kyotaro Horiguchi wrote:
>>> + The memory contexts will be logged based on the log configuration
>>> set. For example:
>>>
>>> How do you think?
>>
>> How about "The memory contexts will be logged in the server log" ?
>> I think "server log" doesn't suggest any concrete target.
>
> Or just using "logged" is enough?
>
> Also I'd like to document that one message for each memory context is
> logged.
> So what about the following?
>
>     One message for each memory context will be logged. For example,


Agreed.

BTW, there was a conflict since c30f54ad732(Detect POLLHUP/POLLRDHUP
while
running queries), attached v9.


Regards,

Hi,

+ * On receipt of this signal, a backend sets the flag in the signal
+ * handler, and then which causes the next CHECK_FOR_INTERRUPTS()

I think the 'and then' is not needed:

  handler which causes the next ...

+        * This is just a warning so a loop-through-resultset will not abort
+        * if one backend logged its memory contexts during the run.

The pid given by arg 0 is not a PostgreSQL server process. Which other backend could it be ?

Thanks

pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Bharath Rupireddy
Date:
Subject: Re: A new function to wait for the backend exit after termination