At Wed, 29 Dec 2021 10:34:31 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in
> On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >
> >
> >
> > On 2021/12/28 9:32, Masahiko Sawada wrote:
> > > Doesn't this query return 64? So the expression "substring(str for
> > > (SELECT max_identifier_length FROM pg_control_init()))" returns the
> > > first 64 characters of the given string while the application_name is
> > > truncated to be 63 (NAMEDATALEN - 1) characters. It also seems to be
> > > fine to use current_setting('max_identifier_length') instead of
> > > max_identifier_length of pg_control_init().
> >
> > Interesting! I agree that current_setting('max_identifier_length') should be used instead. Attached is the updated
versionof the patch. It uses current_setting('max_identifier_length').
>
> Thank you for updating the patch! It looks good to me.
pg_terminate_backend returns just after kill() returns. So I'm afraid
that there's a case where the next access to ft6 happens before the
old connection actually ends on slow machines or under heavy load.
> > BTW it seems confusing that pg_control_init() (also pg_controldata) and GUC report different values as
max_identifier_length.Probably they should return the same value such as NAMEDATALEN - 1. But this change might be
overkill...
>
> Agreed. Probably we can fix it in a separate patch if necessary.
Agree to another patch, but I think we should at least add a caution
that they are different. I'm not sure we can change the context of
ControlFileData.nameDataLen.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center