At Wed, 29 Dec 2021 10:34:31 +0900, Masahiko Sawada <sawada.m...@gmail.com>
wrote in
> On Tue, Dec 28, 2021 at 3:29 PM Fujii Masao <masao.fu...@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 version of 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
