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

From Tom Lane
Subject Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
Date
Msg-id 597521.1627497133@sss.pgh.pa.us
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  ("Bossart, Nathan" <bossartn@amazon.com>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Wed, Jul 28, 2021 at 09:10:35PM +0530, Bharath Rupireddy wrote:
>> 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.

I'm detecting a certain amount of lily-gilding here.  Neither of these
delays are meant for anything except debugging purposes, and nobody as
far as I've heard has ever expressed great concern about identifying
which process they need to attach to for that purpose.  So I think it
is a *complete* waste of time to add any cycles to connection startup
to make these delays more visible.

I follow the idea of using WaitLatch to ensure that the delays are
interruptible by postmaster signals, but even that isn't worth a
lot given the expected use of these things.  I don't see a need to
expend any extra effort on wait-reporting.

            regards, tom lane



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: speed up verifying UTF-8
Next
From: Andres Freund
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum