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.