Re: [PATCH] Expose port->authn_id to extensions and triggers
От | Julien Rouhaud |
---|---|
Тема | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Дата | |
Msg-id | 20220225062552.xnia4nncb3a37gxk@jrouhaud обсуждение исходный текст |
Ответ на | Re: [PATCH] Expose port->authn_id to extensions and triggers (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Expose port->authn_id to extensions and triggers
|
Список | pgsql-hackers |
Hi, On Thu, Feb 24, 2022 at 09:18:26PM -0800, Andres Freund wrote: > > On 2022-02-25 13:01:26 +0800, Julien Rouhaud wrote: > > On Thu, Feb 24, 2022 at 08:44:08PM +0000, Jacob Champion wrote: > > > > > > Yeah... I was following a similar track with the initial work last > > > year, but I dropped it when the cost of implementation started to grow > > > considerably. At the time, though, it looked like some overhauls to the > > > stats framework were being pursued? I should read up on that thread. > > > > Do you mean the shared memory stats patchset? IIUC this is unrelated, as the > > beentry stuff Michael was talking about is a different infrastructure > > (backend_status.[ch]), and I don't think there are any plans to move that to > > dynamic shared memory. > > Until a year ago the backend_status.c stuff was in in pgstat.c - I just split > them out because of the shared memory status work - so it'd not be surprising > for them to mentally be thrown in one bucket. Right. > Basically the type of stats we're trying to move to dynamic shared memory is > about counters that should persist for a while and are accumulated across > connections etc. Whereas backend_status.c is more about tracking the current > state (what query is a backend running, what user, etc). But would it be acceptable to use dynamic shared memory in backend_status and e.g. have a dsa_pointer rather than a fixed length array? That seems like a bad idea for query text in general, but for authn_id for instance it seems less likely to hold gigantic strings, and also have more or less consistent size when provided.
В списке pgsql-hackers по дате отправления: