Re: walsender "wakeup storm" on PG16, likely because of bc971f4025c (Optimize walsender wake up logic using condition variables)

Antonin Houska <ah@cybertec.at>

From: Antonin Houska <ah@cybertec.at>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-08-16T11:20:23Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> wrote:

> On Tue, Aug 15, 2023 at 2:23 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> > I'm not familiar with the condition variable code enough to have an
> > opinion, but the patch seems to resolve the issue for me - I can no
> > longer reproduce the high CPU usage.
> 
> Thanks, pushed.

I try to understand this patch (commit 5ffb7c7750) because I use condition
variable in an extension. One particular problem occured to me, please
consider:

ConditionVariableSleep() gets interrupted, so AbortTransaction() calls
ConditionVariableCancelSleep(), but the signal was sent in between. Shouldn't
at least AbortTransaction() and AbortSubTransaction() check the return value
of ConditionVariableCancelSleep(), and re-send the signal if needed?

Note that I'm just thinking about such a problem, did not try to reproduce it.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com



Commits

  1. De-pessimize ConditionVariableCancelSleep().

  2. Forward received condition variable signals on cancel.