Re: Allow escape in application_name
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Allow escape in application_name |
Дата | |
Msg-id | 20220104.120458.1027561301775557299.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Allow escape in application_name (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | 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 по дате отправления: