On 2023-11-27 17:55:34 +0200, Heikki Linnakangas wrote:
> On 25/10/2023 21:59, Andres Freund wrote:
> > > See attached. It's the same logic as in your patch, just formulatd more
> > > clearly IMHO.
> > Yep, makes sense!
>
> Pushed this. Thanks for the investigation!
Thanks!
On 25/10/2023 21:59, Andres Freund wrote:
See attached. It's the same logic as in your patch, just formulatd more
clearly IMHO.
Yep, makes sense!
Pushed this. Thanks for the investigation!
--
Heikki Linnakangas
Neon (https://neon.tech)
On 25/10/2023 21:59, Andres Freund wrote:
On 2023-10-25 12:17:03 +0300, Heikki Linnakangas wrote:
On 25/10/2023 02:09, Andres Freund wrote:
Because of the inherent delay between the checks of XLogCtl->WalWriterSleeping
and Latch->is_set, we also sometimes end up with multiple processes signalli
Hi,
On 2023-10-25 12:17:03 +0300, Heikki Linnakangas wrote:
> On 25/10/2023 02:09, Andres Freund wrote:
> > Because of the inherent delay between the checks of
> > XLogCtl->WalWriterSleeping
> > and Latch->is_set, we also sometimes end up with multiple processes
> > signalling
> > walwriter, whi
On 25/10/2023 02:09, Andres Freund wrote:
Because of the inherent delay between the checks of XLogCtl->WalWriterSleeping
and Latch->is_set, we also sometimes end up with multiple processes signalling
walwriter, which can be bad, because it increases the likelihood that some of
the signals may be
Hi,
I recently mentioned to Heikki that I was seeing latch related wakeups being
frequent enough to prevent walwriter from doing a whole lot of work. He asked
me to write that set of concerns up, which seems quite fair...
Here's a profile of walwriter while the following pgbench run was ongoing: