Re: [PATCH] Expose port->authn_id to extensions and triggers - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id YwWjqSPH7WtSrjrF@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <jchampion@timescale.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers
Re: [PATCH] Expose port->authn_id to extensions and triggers
List 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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Assertion failure on PG15 with modified test_shm_mq test
Next
From: John Naylor
Date:
Subject: Re: use ARM intrinsics in pg_lfind32() where available