From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | michael(at)paquier(dot)xyz |
Cc: | bossartn(at)amazon(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pryzby(at)telsasoft(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(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-29 07:59:21 |
Message-ID: | 20210729.165921.1599006583688352806.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 29 Jul 2021 09:52:08 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Wed, Jul 28, 2021 at 08:28:12PM +0000, Bossart, Nathan wrote:
> > On 7/28/21, 11:32 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> Agreed to just drop the patch (my opinion about this patch is
> unchanged). Not to mention that wait events are not available at SQL
> level at this stage yet.
I'm +1 to not adding wait event stuff at all. So the only advantage
this patch would offer is interruptivity. I vote +-0.0 for adding that
interruptivity (+1.0 from the previous opinion of mine:p).
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-07-29 08:25:01 | Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns |
Previous Message | Michael Paquier | 2021-07-29 07:16:59 | Re: Some code cleanup for pgbench and pg_verifybackup |