On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, Aug 30, 2024 at 04:10:32PM -0400, Andrew Dunstan wrote:
> > Patch 0001 looks sane to me.
> So does 0002 to me.
Thanks both!
> I'm not much a fan of the addition of
> pgstat_bestart_pre_auth(), which is just a shortcut to set a different
> state in the backend entry to tell that it is authenticating. Is
> authenticating the term for this state of the process startups,
> actually? Could it be more transparent to use a "startup" or
> "starting"" state instead
Yeah, I think I should rename that. Especially if we adopt new wait
states to make it obvious where we're stuck.
"startup", "starting", "initializing", "connecting"...?
> that gets also used by pgstat_bestart() in
> the case of the patch where !pre_auth?
To clarify, do you want me to just add the new boolean directly to
pgstat_bestart()'s parameter list?
> The addition of the new wait event states in 0004 is a good idea,
> indeed,
Thanks! Any thoughts on the two open questions for it?:
1) Should we add a new wait event class rather than reusing IPC?
2) Is the level at which I've inserted calls to
pgstat_report_wait_start()/_end() sane and maintainable?
> and these can be seen in pg_stat_activity once we get out of
> PGSTAT_END_WRITE_ACTIVITY() (err.. Right?).
It doesn't look like pgstat_report_wait_start() uses that machinery.
--Jacob
