From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Shawn Debnath <sdn(at)amazon(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Introduce timeout capability for ConditionVariableSleep |
Date: | 2019-07-23 04:50:40 |
Message-ID: | CA+hUKGL6U8YvGNXzzw7GP0x=e3eKs1nXRQdSiNWns=bLTaoDUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 16, 2019 at 1:11 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Jul 12, 2019 at 11:03 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuro Yamada | 2019-07-23 04:51:04 | Re: progress report for ANALYZE |
Previous Message | Tsunakawa, Takayuki | 2019-07-23 03:46:59 | RE: Speed up transaction completion faster after many relations are accessed in a transaction |