Re: Allow escape in application_name

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "ikedamsh(at)oss(dot)nttdata(dot)com" <ikedamsh(at)oss(dot)nttdata(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Allow escape in application_name
Date: 2021-12-16 06:33:56
Message-ID: aaa7a830-55c5-fafd-9606-8437b7c0d052@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/12/16 11:53, kuroda(dot)hayato(at)fujitsu(dot)com wrote:
> Dear Fujii-san,
>
> Thank you for updating! I read your patches and I have
> only one comment.
>
>> if (strcmp(keywords[i], "application_name") == 0 &&
>> values[i] != NULL && *(values[i]) != '\0')
>
> I'm not sure but do we have a case that values[i] becomes NULL
> even if keywords[i] is "application_name"?

No for now, I guess. But isn't it safer to check that, too? I also could not find strong reason why that check should be dropped. But you'd like to drop that?

> I think other parts are perfect.

Thanks for the review! At first I pushed 0001 patch.

BTW, 0002 patch adds the regression test that checks pg_stat_activity.application_name. But three months before, we added the similar test when introducing postgres_fdw.application_name GUC and reverted/removed it because it's not stable [1]. So we should review carefully whether the test 0002 patch adds may have the same issue or not. As far as I read the patch, ISTM that the patch has no same issue. But could you double check that?

[1]
https://postgr.es/m/848ff477-effd-42b9-8b25-3f7cfe289398@oss.nttdata.com

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-12-16 06:50:54 Addition of --no-sync to pg_upgrade for test speedup
Previous Message Greg Stark 2021-12-16 06:05:07 Re: Documenting when to retry on serialization failure