Re: Shouldn't GSSAPI and SSL code use FeBeWaitSet?
От | Thomas Munro |
---|---|
Тема | Re: Shouldn't GSSAPI and SSL code use FeBeWaitSet? |
Дата | |
Msg-id | CA+hUKGL-rBXW4b143+1Vd2RmxVhvjgXUk10K-GNoPjifzfd5GA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Shouldn't GSSAPI and SSL code use FeBeWaitSet? (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
On Mon, Feb 24, 2020 at 4:55 PM Thomas Munro <thomas.munro@gmail.com> wrote: > On Mon, Feb 24, 2020 at 4:49 PM Thomas Munro <thomas.munro@gmail.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.
В списке pgsql-hackers по дате отправления: