Re: pg_reload_conf() synchronously

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_reload_conf() synchronously
Дата
Msg-id Y2X0FExL+JzzL+yp@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_reload_conf() synchronously  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_reload_conf() synchronously
Список pgsql-hackers
On Fri, Nov 04, 2022 at 09:51:08PM -0700, Andres Freund wrote:
> On 2022-11-04 23:35:21 -0400, Tom Lane wrote:
>> True, but do we have any such cases?
>
> I know I hit it twice and gave up on the tests.

Still, is there any need for a full-blown facility for the case of an
individual backend?  Using a new function to track that all the
changes are in effect is useful for isolation tests, less for single
sessions where a function to wait for all the backends is no different
than a \c to enforce a reload because both tests would need an extra
step (on top of making parallel tests longer if something does a long
transaction?).

As far as I know, Gurjeet has been annoyed only with non-user-settable
GUCs for one connection (correct me of course), there was nothing
fancy with isolation tests, yet.  Not saying that this is useless for
isolation tests, this would have its cases for assumptions where
multiple GUCs need to be synced across multiple sessions, but it seems
to me that we have two different cases in need of two different
solutions.
--
Michael

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_reload_conf() synchronously
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file