Re: System username in pg_stat_activity
От | Magnus Hagander |
---|---|
Тема | Re: System username in pg_stat_activity |
Дата | |
Msg-id | CABUevEwnqbG7SBSKVUEyYCSS72eaN32RFbAtPUs53OjtPpeJGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: System username in pg_stat_activity (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: System username in pg_stat_activity
Re: System username in pg_stat_activity |
Список | pgsql-hackers |
On Fri, Feb 16, 2024 at 8:55 PM Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2024-01-12 17:16:53 +0100, Magnus Hagander wrote: > > On Thu, Jan 11, 2024 at 5:55 PM Bertrand Drouvot > > <bertranddrouvot.pg@gmail.com> wrote: > > > On Thu, Jan 11, 2024 at 02:24:58PM +0100, Magnus Hagander wrote: > > > > On Wed, Jan 10, 2024 at 3:12 PM Bertrand Drouvot > > > > <bertranddrouvot.pg@gmail.com> wrote: > > > > > > > > > > If we go the 2 fields way, then what about auth_identity and auth_method then? > > > > > > > > > > > > Here is an updated patch based on this idea. > > > > > > Thanks! > > > > > > + <row> > > > + <entry role="catalog_table_entry"><para role="column_definition"> > > > + <structfield>auth_method</structfield> <type>text</type> > > > + </para> > > > + <para> > > > + The authentication method used for authenticating the connection, or > > > + NULL for background processes. > > > + </para></entry> > > > > > > I'm wondering if it would make sense to populate it for parallel workers too. > > > I think it's doable thanks to d951052, but I'm not sure it's worth it (one could > > > join based on the leader_pid though). OTOH that would be consistent with > > > how the SYSTEM_USER behaves with parallel workers (it's populated). > > > > I guess one could conceptually argue that "authentication happens int > > he leader". But we do populate it with the other user records, and > > it'd be weird if this one was excluded. > > > > The tricky thing is that pgstat_bestart() is called long before we > > deserialize the data. But from what I can tell it should be safe to > > change it per the attached? That should be AFAICT an extremely short > > window of time longer before we report it, not enough to matter. > > I don't like that one bit. The whole subsystem initialization dance already is > quite complicated, particularly for pgstat, we shouldn't make it more > complicated. Especially not when the initialization is moved quite a bit away > from all the other calls. > > Besides just that, I also don't think delaying visibility of the worker in > pg_stat_activity until parallel worker initialization has completed is good, > that's not all cheap work. > > > Maybe I am missing something, but why aren't we just getting the value from > the leader's entry, instead of copying it? The answer to that would be "because I didn't think of it" :) Were you thinking of something like the attached? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Вложения
В списке pgsql-hackers по дате отправления: