Re: Repeatability of installcheck for test_oat_hooks

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Repeatability of installcheck for test_oat_hooks
Дата
Msg-id Yrpv5ZP/02dk5rpL@paquier.xyz
обсуждение исходный текст
Ответ на Repeatability of installcheck for test_oat_hooks  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, Jun 28, 2022 at 10:12:48AM +0900, Michael Paquier wrote:
> As far as I can see, test_oat_hook has no need to keep around the
> extra role it creates as part of the regression tests, because at the
> end of the test there are no objects that depend on it.  Wouldn't it
> be better to make the test self-isolated?  NO_INSTALLCHECK is set in
> the module because of the issue with caching and the namespace search
> hooks, but it seems to me that we'd better make the test self-isolated
> in the long term, like in the attached.

And actually, I have found a second issue here.  The tests issue a
GRANT on work_mem, like that:
GRANT SET ON PARAMETER work_mem TO PUBLIC;

This has as effect to leave around an entry in pg_parameter_acl, which
is designed this way in aclchk.c.  However, this interacts with
guc_privs.sql in unsafe_tests, because those tests include similar
queries GRANT queries, also on work_mem.  So, if one issues an
installcheck on test_oat_modules followed by an installcheck in
unsafe_tests, the latter fails.  I think that we'd better add an extra
REVOKE to clear the contents of pg_parameter_acl.
--
Michael

Вложения

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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup
Следующее
От: "wangw.fnst@fujitsu.com"
Дата:
Сообщение: RE: Perform streaming logical transactions by background workers and parallel apply