On 2021/04/05 21:03, torikoshia wrote:
> On 2021-04-05 12:59, Fujii Masao wrote:
>> On 2021/04/05 12:20, Zhihong Yu wrote:
>
> Thanks for reviewing!
>
>>> + * 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:
>
> Although I wonder either would be fine, removed the words.
>
>>> + * 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 ?
>>
>> This is the comment that I added wrongly. So the comment should be
>> "This is just a warning so a loop-through-resultset will not abort
>> if one backend terminated on its own during the run.",
>> like pg_signal_backend(). Thought?
>
> +1.
>
> Attached v10 patch.
Thanks for updating the patch!
I updated the patch as follows. Could you check the attached patch?
+ Memory contexts will be logged based on the log configuration set.
+ See <xref linkend="runtime-config-logging"/> for more information.
Those memory contexts are logged at LOG level, but they are not sent to
a client whatever the setting of client_min_messages. I think
this information should be documented. So I updated the document as follows.
These memory contexts will be logged at <literal>LOG</literal>
message level. They will appear in the server log based on
the log configuration set (See <xref linkend="runtime-config-logging"/>
for more information), but will not be sent to the client whatever
the setting of <xref linkend="guc-client-min-messages"/>.
+ Only superusers can log the memory contexts.
We can read this description as "only superusers can request to log ...".
But ISTM that we can also read this as "only superusers can log (dump)
the memory contexts of its backend". Right? To avoid this confusion,
I updated this description as follows.
Only superusers can request to log the memory contexts.
I added the following note about the performance overhead by this function.
Note that frequent calls to this function could incur significant overhead,
because it may generate a large number of log messages.
I also added some comments.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
