On Thu, Nov 7, 2024 at 2:56 PM Andres Freund <and...@anarazel.de> wrote: > It does actually make things harder - what if somebody added a > pgstat_report_activity() somewhere between the call? It would suddenly get > lost after the second "initialization". Actually, the proposed patch already > has weird, externally visible, consequences - the application name is set, > then suddenly becomes unset, then is set again.
Oh... I think that alone is enough to change my mind; I neglected the effects of that little pgstat_report_appname() stinger... > Additionally PGSTAT_BEGIN_WRITE_ACTIVITY() would already happen twice if you > initialize twice... Sure. I was just trying not to introduce that to _all_ backend code paths, but it sounds like that's not a concern. (Plus, it turns out to be four calls, due again to the application_name reporting...) > That doesn't seem like a reason to just initialize twice to me. If you have > one initialization step that properly initializes everything to a minimal > default state, you then can have granular functions that set up the user, > database, SSL, GSS information separately. I will start work on that then (unless Michael has already beaten me to it?). > But more importantly, because of not having nesting, adding one "coarse" "wait > event" means that anyone adding a wait event at a finer grade suddenly needs > to be aware of all the paths that could lead to the execution of the new > code and change all of them to not use the wait event anymore. It imposes a > tax on measuring actual "out of postgres" wait events. > > One very useful wait event would be for memory allocations that hit the > kernel. Those can take a fairly long time, because they might need to write > dirty buffers to disk before there is enough free memory. Now imagine that we > redefine the system memory allocator (or just postgres') so that all memory > allocations from the kernel use a wait event. Now suddenly all that code that > uses "coarse" wait events suddenly has a *rare* path - because most of the > time > we can carve memory out of a larger OS level memory allocation - where wait > events would be nested. Okay, that makes a lot of sense. I will plumb these down as far as I can. Thanks very much! --Jacob
