Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Дата
Msg-id 848ff477-effd-42b9-8b25-3f7cfe289398@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 2021/09/08 7:46, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> Pushed 0001 patch. Thanks!
> 
> The buildfarm shows that this test case isn't terribly reliable.

Yes... Thanks for reporting this!


> TBH, I think you should just remove the test case altogether.
> It does not look useful enough to justify a permanent expenditure of
> testing cycles, never mind the amount of effort that would be needed to
> stabilize it.

Ok, I will remove the tests.

Kuroda-san is proposing the additional feature which allows
postgres_fdw.application_name to include escape characters.
If we commit the feature, it's worth adding the similar tests
checking that the escape characters there are replaced with
expected values. So it's better to investigate what made
the tests fail, not to cause the same tests failure later.

The tests use postgres_fdw_disconnect_all() to close the existing
remote connections before establishing new remote connection
with new application_name setting. Then they check that
the expected application_name appears in pg_stat_activity.
The cause of the issue seems to be that it can take a bit time for
the existing remote connection (i.e., its corresponding backend)
to exit after postgres_fdw_disconect_all() is called.
So application_name of the existing remote connection also could
appear in pg_stat_activity when it's checked next time.

If this analysis is right, the tests that the upcoming patch adds
should handle the case where the existing remote connection
can appear in pg_stat_activity after postgres_fdw_disconect_all().

Regards,

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Data loss when '"json_populate_recorset" with long column name
Следующее
От: Greg Nancarrow
Дата:
Сообщение: Re: Bug in query rewriter - hasModifyingCTE not getting set