Re: Introduce timeout capability for ConditionVariableSleep
От | Thomas Munro |
---|---|
Тема | Re: Introduce timeout capability for ConditionVariableSleep |
Дата | |
Msg-id | CA+hUKGL6U8YvGNXzzw7GP0x=e3eKs1nXRQdSiNWns=bLTaoDUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introduce timeout capability for ConditionVariableSleep (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jul 16, 2019 at 1:11 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Jul 12, 2019 at 11:03 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > I pushed this too. It's a separate commit, because I think there is > > at least a theoretical argument that it should be back-patched. I'm > > not going to do that today though, because I doubt anyone is relying > > on ConditionVariableSignal() working that reliably yet, and it's > > really with timeouts that it becomes a likely problem. > > To make it work reliably, you'd need to be sure that a process can't > ERROR or FATAL after getting signaled and before doing whatever the > associated work is (or that if it does, it will first pass on the > signal). Since that seems impossible, I'm not sure I see the point of > trying to do anything at all. I agree that that on its own doesn't fix problems in <some non-existent client of this facility>, but that doesn't mean we shouldn't try to make this API as reliable as possible. Unlike typical CV implementations, our wait primitive is not atomic. When we invented two-step wait, we created a way for ConditionVariableSignal() to have no effect due to bad timing. Surely that's a bug. -- Thomas Munro https://enterprisedb.com
В списке pgsql-hackers по дате отправления: