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

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "Kyotaro Horiguchi" <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <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 20:28:12
Message-ID: AD0B46DD-AD96-4D5C-85F5-1B987D86D83E@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/28/21, 11:32 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

+1. The proposed patch doesn't make the delay visibility any worse
than what's already there.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-07-28 20:45:07 Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Previous Message Jacob Champion 2021-07-28 20:10:53 Re: [PATCH] test/ssl: rework the sslfiles Makefile target