On 2020/10/05 20:32, Bharath Rupireddy wrote:
> On Mon, Oct 5, 2020 at 9:45 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>>> I see the errmsg() with plain texts in other places in the code base
>>> as well. Is it that we look at the error message and if it is a plain
>>> text(without database objects or table data), we decide to have no
>>> translation? Or is there any other policy?
>>
>> I was thinking that elog() basically should be used to report this
>> debug message, instead, but you used ereport() because maybe
>> you'd like to add detail message about connection error. Is this
>> understanding right? elog() uses errmsg_internal().
>>
>
> Yes that's correct.
>
>>
>> So if ereport() is used as an aternative of elog() for some reasons,
>> IMO errmsg_internal() should be used. Thought?
>>
>
> Yes, this is apt for our case.
>
>>
>> OTOH, the messages you mentioned are not debug ones,
>> so basically ereport() and errmsg() should be used, I think.
>>
>
> In connection.c file, yes they are of ERROR type. Looks like it's not
> a standard to use errmsg_internal for DEBUG messages that require no
> translation with ereport
>
> (errmsg("wrote block details for %d blocks", num_blocks)));
> (errmsg("MultiXact member stop limit is now %u based on MultiXact %u
> (errmsg("oldest MultiXactId member is at offset %u",
>
> However, there are few other places, where errmsg_internal is used for
> DEBUG purposes.
>
> (errmsg_internal("finished verifying presence of "
> (errmsg_internal("%s(%d) name: %s; blockState:
>
> Having said that, IMHO it's better to keep the way it is currently in
> the code base.
Agreed.
>
>>
>>> Thanks. Attaching v10 patch. Please have a look.
>>
>> Thanks for updating the patch! I will mark the patch as ready for committer in CF.
>> Barring any objections, I will commit that.
>>
>
> Thanks a lot for the review comments.
I pushed the patch. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION