From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shouldn't GSSAPI and SSL code use FeBeWaitSet? |
Date: | 2020-02-26 23:31:31 |
Message-ID: | CA+hUKGL-rBXW4b143+1Vd2RmxVhvjgXUk10K-GNoPjifzfd5GA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 24, 2020 at 4:55 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, Feb 24, 2020 at 4:49 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > While working on a patch to reuse a common WaitEventSet for latch
> > waits, I noticed that be-secure-gssapi.c and be-secure-openssl.c don't
> > use FeBeWaitSet. They probably should, for consistency with
> > be-secure.c, because that surely holds the socket they want, no?
>
> Hmm. Perhaps it's like that because they're ignoring their latch
> (though they pass it in just because that interface requires it). So
> then why not reset it and process read interrupts, like be-secure.c?
Perhaps the theory is that it doesn't matter if they ignore eg
SIGQUIT, because authentication_timeout will come along in (say) 60
seconds and exit anyway? That makes me wonder whether it's OK that
StartupPacketTimeoutHandler() does proc_exit() from a signal handler.
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2020-02-27 01:18:16 | Re: Allow auto_explain to log plans before queries are executed |
Previous Message | Thomas Munro | 2020-02-26 23:17:45 | Re: Reducing WaitEventSet syscall churn |