From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [doc] modifying unit from characters to bytes |
Date: | 2020-07-09 12:59:32 |
Message-ID: | 9eefa8b88d42516d2027ff359aca9cb6@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-07-09 13:47, Fujii Masao wrote:
> On 2020/07/08 17:12, Daniel Gustafsson wrote:
>>> On 8 Jul 2020, at 10:05, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
>>> wrote:
>>>
>>> On 2020/07/08 16:17, Daniel Gustafsson wrote:
>>>>> On 8 Jul 2020, at 04:25, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
>>>>> wrote:
>>>>>
>>>>> On 2020/07/08 10:54, torikoshia wrote:
>>>>>> Hi,
>>>>>> The manual describes the size of pg_stat_activity.query
>>>>>> as below:
>>>>>> | By default the query text is truncated at 1024 characters;
>>>>>> When considering multibyte characters, it seems more
>>>>>> accurate to change the unit from "characters" to "bytes".
>>>>>
>>>>> Agreed. Barring any objection, I will commit this patch.
>>>> +1 to commit this patch, following the link to
>>>> track_activity_query_size it's
>>>> even specified to be bytes there. IIRC the NULL terminator is also
>>>> included in
>>>> the 1024 bytes which prevents it from being 1024 characters even for
>>>> non-multibyte.
>>>
>>> Yes, so we should document "truncated at 1023 bytes" for accuracy,
>>> instead?
>>> This might be more confusing for users, though....
>>
>> I think that's overcomplicating things, since we do (will) specify
>> bytes and
>> not characters.
>
> Agreed. So I pushed the proposed patch. Thanks!
Thanks for applying!
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-07-09 13:03:10 | Re: Implement UNLOGGED clause for COPY FROM |
Previous Message | Petr Jelinek | 2020-07-09 12:44:56 | Re: replication_origin and replication_origin_lsn usage on subscriber |