Re: [PATCH] Expose port->authn_id to extensions and triggers

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [PATCH] Expose port->authn_id to extensions and triggers
Дата
Msg-id Yj6wU9DZ7c6MHfTb@paquier.xyz
обсуждение исходный текст
Ответ на Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
Ответы Re: [PATCH] Expose port->authn_id to extensions and triggers
Список pgsql-hackers
On Thu, Mar 24, 2022 at 05:44:06PM +0000, Jacob Champion wrote:
> On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
>> Another option would be to make it a GUC. With a bit of care it could be
>> automatically synced by the existing parallelism infrastructure...
>
> Like a write-once, PGC_INTERNAL setting? I guess I don't have any
> intuition on how that would compare to the separate-global-and-accessor
> approach. Is the primary advantage that you don't have to maintain the
> serialization logic, or is there more to it?

Hmm.  That would be a first for a GUC, no?  It is not seem natural
compared to the other information pieces passed down from the leader
to the workers.

+extern SharedPort MyProcShared;

This naming is interesting, and seems to be in line with a couple of
executor structures that share information across workers.  Still
that's a bit inconsistent as Shared is used once at the beginning and
once at the end?  I don't have a better idea on top of my mind.

Anyway, wouldn't it be better to reverse the patch order, introducing
the shared Proc information first and then build the parallel-safe
function on top of it?
--
Michael

Вложения

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: make MaxBackends available in _PG_init