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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [PATCH] Expose port->authn_id to extensions and triggers
Дата
Msg-id YwWjqSPH7WtSrjrF@paquier.xyz
обсуждение исходный текст
Ответ на Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <jchampion@timescale.com>)
Ответы Re: [PATCH] Expose port->authn_id to extensions and triggers
Re: [PATCH] Expose port->authn_id to extensions and triggers
Список pgsql-hackers
On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
> On 8/23/22 01:53, Drouvot, Bertrand wrote:
>> @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)
>>     MyProcPid = getpid();
>>     MyStartTimestamp = GetCurrentTimestamp();
>>     MyStartTime = timestamptz_to_time_t(MyStartTimestamp);
>> +   memset(&MyClientConnectionInfo, 0, sizeof(MyClientConnectionInfo));
>>
>>     /*
>>      * Set a different global seed in every process.  We want something
>
> When can we rely on static initialization, and when can't we? Is there a
> concern that the memory could have been polluted from before the
> postmaster's fork?

My main worry here is EXEC_BACKEND, where we would just use our own
implementation of fork(), and it is a bad idea at the end to leave
that untouched while we could have code paths that attempt to access
it.  At the end, I have moved the initialization at the same place as
where we set MyProcPort for a backend in BackendInitialize(), mainly
as a matter of consistency because ClientConnectionInfo is aimed at
being a subset of that.  And applied.
--
Michael

Вложения

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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Assertion failure on PG15 with modified test_shm_mq test
Следующее
От: John Naylor
Дата:
Сообщение: Re: use ARM intrinsics in pg_lfind32() where available