Re: Allow escape in application_name - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Allow escape in application_name
Date
Msg-id 20220104.120458.1027561301775557299.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Allow escape in application_name  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: ICU for global collation
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions