De-pessimize ConditionVariableCancelSleep(). Commit b91dd9de was concerned with a theoretical problem with our non-atomic condition variable operations. If you stop sleeping, and then cancel the sleep in a separate step, you might be signaled in between, and that could be lost. That doesn't matter for callers of ConditionVariableBroadcast(), but callers of ConditionVariableSignal() might be upset if a signal went missing like this.
Commit bc971f4025c interacted badly with that logic, because it doesn't use ConditionVariableSleep(), which would normally put us back in the wait list. ConditionVariableCancelSleep() would be confused and think we'd received an extra signal, and try to forward it to another backend, resulting in wakeup storms. New idea: ConditionVariableCancelSleep() can just return true if we've been signaled. Hypothetical users of ConditionVariableSignal() would then still have a way to deal with rare lost signals if they are concerned about that problem. Back-patch to 16, where bc971f4025c arrived. Reported-by: Tomas Vondra <tomas.von...@enterprisedb.com> Reviewed-by: Andres Freund <and...@anarazel.de> Discussion: https://postgr.es/m/2840876b-4cfe-240f-0a7e-29ffd66711e7%40enterprisedb.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5ffb7c775062ef18756e515ac96f06d012cbb950 Modified Files -------------- src/backend/storage/lmgr/condition_variable.c | 16 ++++++---------- src/include/storage/condition_variable.h | 2 +- 2 files changed, 7 insertions(+), 11 deletions(-)