On Tue, Jan 4, 2022 at 12:05 PM Kyotaro Horiguchi
<horikyota....@gmail.com> wrote:
>
> 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.
The test does pg_terminate_backend() with a timeout, and in this case,
don't we wait for the backend to end after sending the signal?
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
