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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: bossartn(at)amazon(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Date: 2021-07-28 02:42:15
Message-ID: 20210728.114215.2096502396299516083.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

- 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-07-28 02:52:39 RE: [bug?] Missed parallel safety checks, and wrong parallel safety
Previous Message David Rowley 2021-07-28 02:39:28 Re: Slim down integer formatting