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
-
De-pessimize ConditionVariableCancelSleep().
- acc5c4fd8f83 16.0 landed
- 5ffb7c775062 17.0 landed
-
Forward received condition variable signals on cancel.
- b91dd9de5ea0 13.0 cited