Postgres Pro
Downloads
Home   >   mailing lists

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

From Antonin Houska
Subject Re: walsender "wakeup storm" on PG16, likely because of bc971f4025c (Optimize walsender wake up logic using condition variables)
Date
Msg-id 3029.1692184823@antos
Whole thread Raw
In response to Re: walsender "wakeup storm" on PG16, likely because of bc971f4025c (Optimize walsender wake up logic using condition variables)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: walsender "wakeup storm" on PG16, likely because of bc971f4025c (Optimize walsender wake up logic using condition variables)
List pgsql-hackers
Tree view 
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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: [PoC] pg_upgrade: allow to upgrade publisher node