From: | Shawn Debnath <sdn(at)amazon(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Introduce timeout capability for ConditionVariableSleep |
Date: | 2019-03-12 23:24:54 |
Message-ID: | eeb06007ccfe46e399df6af18bfcd15a@EX13D05UWC002.ant.amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Postgres today doesn't support waiting for a condition variable with a
timeout, although the framework it relies upon, does. This change wraps
the existing ConditionVariableSleep functionality and introduces a new
API, ConditionVariableTimedSleep, to allow callers to specify a timeout
value.
A scenario that highlights this use case is a backend is waiting on
status update from multiple workers but needs to time out if that signal
doesn't arrive within a certain period. There was a workaround prior
to aced5a92, but with that change, the semantics are now different.
I chose to go with -1 instead of 0 for the return from
ConditionVariableTimedSleep to indicate timeout error as it seems
cleaner for this API. WaitEventSetWaitBlock returns -1 for timeout but
WaitEventSetWait treats timeout as 0 (to represent 0 events indicating
timeout).
If there's an alternative, cleaner way to achieve this outcome, I am all
ears.
Thanks.
--
Shawn Debnath
Amazon Web Services (AWS)
Attachment | Content-Type | Size |
---|---|---|
0001-Introduce-timeout-capability-for-ConditionVariableSleep-v1.patch | text/plain | 3.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-03-12 23:28:31 | Re: Should we add GUCs to allow partition pruning to be disabled? |
Previous Message | Andres Freund | 2019-03-12 23:12:04 | Re: Using condition variables to wait for checkpoints |