Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep

On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote:
> On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > - It seems that the additional wait-event is effectively useless for
> > most of the processes. Considering that this feature is for debugging
> > purpose, it'd be better to use ps display instead (or additionally)
> > if we want to see the wait event anywhere.
>
> Hm. That's a good idea to show up in the ps display.

Keep in mind that ps is apparently so expensive under windows that the GUC
defaults to off.

The admin can leave the ps display off, but I wonder if it's of any concern
that something so expensive can be caused by an unauthenticated connection.

> > The events of autovacuum workers can be seen in pg_stat_activity properly.
> >
> > For client-backends, that state cannot be seen in
> > pg_stat_activity. That seems inevitable since backends aren't
> > allocated a PGPROC entry yet at that time. (So the wait event is set
> > to local memory as a safety measure in this case.) On the other hand,
> > I find it inconvenient that the ps display is shown as just "postgres"
> > while in that state. I think we can show "postgres: preauth waiting"
> > or something. (It is shown as "postgres: username dbname [conn]
> > initializing" while PostAuthDelay)
>
> Hm. Is n't it better to show something like below in the ps display?
> for pre_auth_delay: "postgres: pre auth delay"
> for post_auth_delay: "postgres: <<existing message>> post auth delay"
>
> But, I'm not sure whether this ps display thing will add any value to
> the end user who always can't see the ps display. So, how about having
> both i.e. ps display (useful for pre auth delay cases) and wait event
> (useful for post auth delay)?