Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Date
Msg-id 20210728.114215.2096502396299516083.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Hello.

At Tue, 27 Jul 2021 11:04:09 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in 
> On Mon, Jul 26, 2021 at 11:03 PM Bossart, Nathan <bossartn@amazon.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).

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

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)

Background workers behave the same way to client backends for the same
reason to the above. We might be able to *fix* that but I'm not sure
it's worth doing that only for this specific case.

Autovacuum launcher is seen in pg_stat_activity but clients cannot
start connection before autovac launcher starts unless unless process
startup time is largely fluctuated.  So the status is effectively
useless in regard to the process.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Slim down integer formatting
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: [bug?] Missed parallel safety checks, and wrong parallel safety