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

On Wed, Jul 28, 2021 at 8:12 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> Hello.
>
> At Tue, 27 Jul 2021 11:04:09 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> > PSA v3 patch.
>
> I have some comments.
>
> - No harm, but it's pointless to feed MyLatch to WaitLatch when
> WL_LATCH_SET is not set (or rather misleading).

+1. I can send NULL to WaitLatch.

> - 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.

> 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)?

Regards,
Bharath Rupireddy.